FS#53840 - [evolution] Shows wrong version string

Attached to Project: Arch Linux
Opened by Ralf Mardorf (Ralf) - Wednesday, 26 April 2017, 08:59 GMT
Last edited by Jan de Groot (JGC) - Saturday, 21 October 2017, 16:47 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Jan Alexander Steffens (heftig)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Hi,

several Arch users experience issues with Evolution. I don't, so I can't report those bugs.
However, when those users sent requests to the Evolution mailing list, I noticed that they reported the wrong version.

I don't know why not the official releases from upstream are packaged, however, if you package commits from git, then build with
-DVERSION_SUBSTRING="+gitXXXXXX" \
-DVERSION_COMMENT="+gitXXXXXX"
, without doing so "evolution -v" does show another version then actually was build and packaged.

From the mailing list:

"[snip] the detailed Arch versions are shown below. Maybe those commits are ok, however, at least the Arch versions aren't simply

[rocketmouse@archlinux ~]$ evolution -v
evolution 3.24.2

they are 3.24.1+git:

[rocketmouse@archlinux ~]$ grep _commit /var/abs/extra/evolution/PKGBUILD
_commit=fc6d11eb4aab2cb44a6f63ea540d14138d278605 # gnome-3-24 [snip]"
- https://mail.gnome.org/archives/evolution-list/2017-April/msg00120.html

"[snip] You surely do not have 3.24.2, that had not been released yet. The way the Arch maintainer does his/her duty leads only to confusion for users and nothing else. It's a very wrong approach, from my point of view. The packager should use
-DVERSION_SUBSTRING="+gitXXXXXX", eventually
-DVERSION_COMMENT="+gitXXXXXX", (though none of this is shown in Help->About (I'm changing it for the next release), only in `evolution --version`) during the build (pass to cmake command) and skip the commit where the version is bumped just after the previous release, then everything will make sense and not be confusing. [snip]"
- https://mail.gnome.org/archives/evolution-list/2017-April/msg00128.html

Steps to reproduce:

[rocketmouse@archlinux ~]$ pacman -Si evolution{,-ews,-data-server,-bogofilter,-spamassassin}|grep Ve
Version : 3.24.1+6+gfc6d11eb4a-1
Version : 3.24.1-1
Version : 3.24.1+5+g98589a27b-2
Version : 3.24.1+6+gfc6d11eb4a-1
Version : 3.24.1+6+gfc6d11eb4a-1
[rocketmouse@archlinux ~]$ evolution -v
evolution 3.24.2

Regards,
Ralf
This task depends upon

Closed by  Jan de Groot (JGC)
Saturday, 21 October 2017, 16:47 GMT
Reason for closing:  Won't implement
Additional comments about closing:  See last comment.
Comment by Jan de Groot (JGC) - Wednesday, 26 April 2017, 10:21 GMT
IMHO this is only cosmetic. Distributions package software with shitloads of patches and changes to default enabled/disabled options most of the time, so even when evolution -v shows 3.24.1 there's no warranty that it's the same 3.24.1 you would get when building from a released tarball with default options.

If upstream cares about versions in evolution -v output, then upstream should not commit "Post-release version bump" but do that on release.

We build from git because of 2 main reasons:
- easier to add upstream committed patches
- release tarballs are often generated with broken tools

Comment by Ralf Mardorf (Ralf) - Wednesday, 26 April 2017, 11:29 GMT
Hi,

actually it were _several_ Arch users who sent requests, providing wrong version information. I posted to the mailing list only to correct the version information. What other distros might do is irrelevant for us. It's also unimportant if upstream decides to default to 3.24.1 or 3.24.2, if you compile and package 3.24.1gitabcd. In my experiences, based on following the Evolution mailing list, official releases from upstream are sometimes buggy, but not more or less often, than for the majority of any other software, so IMO there's no reason to divert from the Arch policy. However, if you feel the need to build from git, I don't understand why you won't build with -DVERSION_SUBSTRING="+gitXXXXXX" -DVERSION_COMMENT="+gitXXXXXX".
Anyway, I only wanted to inform you about an issue that arise on the Evolution mailing list, feel free to ignore it.

Regards,
Ralf
Comment by Jan de Groot (JGC) - Wednesday, 26 April 2017, 12:54 GMT
We decided to use git for all GNOME PKGBUILDs when we started packaging 3.22. So far this has worked out fine, makes cherry-picking patches or updating to a branch snapshot much easier. I could add -DVERSION_SUBSTRING= and/or -DVERSION_COMMENT= to our PKGBUILD so it includes the git commit or Archlinux pkgver, but I won't go into git log to find out which commit does a premature version bump so I can revert that when packaging a branch snapshot.
Comment by Ralf Mardorf (Ralf) - Wednesday, 26 April 2017, 13:26 GMT
This IMO is a good solution, so I asked upstream to care about the "premature" version bump. https://mail.gnome.org/archives/evolution-list/2017-April/msg00135.html
Comment by Ralf Mardorf (Ralf) - Wednesday, 26 April 2017, 15:01 GMT
Update:

"[snip]
Hi,
okay, that sounds better. Let him use just one of those, better might
be -DVERSION_SUBSTRING="gitXXXXX", which will generate "X.Y.ZgitXXXXX".

I understand that it's a pita to hunt for "Post-release version bump"
commits, but it also makes sense to bump the version after release,
thus it's clear that this version is not 'the previous version'. Or I
just got use to this approach during the years. Each approach has its
pros and cons.
Thanks and bye,
Milan" - https://mail.gnome.org/archives/evolution-list/2017-April/msg00141.html
Comment by Eli Schwartz (eschwartz) - Friday, 04 August 2017, 01:13 GMT
Not really sure what the bug here is, bumping the version to an unreleased version is an anti-pattern -- sane upstreams either leave the version alone, bump it to ${releaseversion}-dev, or attempt to redefine the version as part of the configure step, using `git describe`.

They don't expect downstream packagers or other people building the software to work around the fact that their source code is telling a blatant lie.

Loading...