[ Solved ] Packages with long version with "+g" in their names

mountaineerbr · 2019-01-26 18:46:56

I was wondering why many packages for updates have versions with the "+g" in them, as in 'libtool-2.4.6+42+gb88cebd5-1' for example.

Does that letter g relate to gamma-type of software , like a rc release? Or does it mean that some patches were applied to the package but were not incorporated in the upstream version yet?

I did come across that reference at some point, but I lost it... Also, I could not find related material in the Arch wiki or forum, I am sure some one must have explained that already at some point, Thanks

Last edited by mountaineerbr (2019-01-26 19:24:22)

Slithery · 2019-01-26 19:14:23

It only occurs with VCS packages and refers to the checksum of the commit from which the package was built. For more information read...
https://wiki.archlinux.org/index.php/VC … )_function

For your example take a look at the libtool PKGBUILD. The following lines along with man git-describe should explain what's happening...

_commit=b88cebd510add4420dd8f5367e3cc6e6e1f267cd
source=(git+https://git.savannah.gnu.org/git/libtool.git#commit=$_commit)
...
pkgver() {
  cd libtool
  git describe --tags | sed 's/-/+/g;s/^v//'
}

mountaineerbr · 2019-01-26 19:22:27

Thank you very much for the explanation and reference. There is not a simpler answer but yours. Cheers!

PS: You know, I did try searching for those numbers in three different PKGBUILDs, but I reckon I did it wrong or too fast or too unsurely because I could not find that link of numbers you pointed out... and 'g' , as a delimiter to preserve monotonicity of custom revision numbers of pkgs and versioning decisions from upstream ( I get that now ), could denote git as a bargain

Last edited by mountaineerbr (2019-01-26 22:08:06)

eschwartz · 2019-01-27 02:14:16

The g comes from the fact that git prefixes the commit sha1 with a g.

Monotonicity of versioning comes from the "r" which precedes the commit count -- i.e. the 42. And if you're sharp-eyed and you spotted that there is no r in that libtool version, then you're entirely right -- that package has no monotonicity in its pkgver function and if stable release 2.4.6 plus 42 commits on master is ever superseded by stable release 2.4.6.1, it will be seen as a downgrade and we'll have to add an epoch. Fortunately it is doubtful that libtool will do any such thing -- it is hard enough to get them to release anything at all.

But we do have bugs like https://bugs.archlinux.org/task/60830 because zeitgeist 1.0 plus 1 commit on master at commit hash (g)1bcc8585, got downgraded to 1.0.1 (which is the same as 1.0+1 but considered lesser due to its not using a commit hash).
Apparently the zeitgeist developers *do* feel fine with changing the number of components in their release versioning.

mountaineerbr · 2019-01-27 04:12:07

eschwartz wrote:

But we do have bugs like https://bugs.archlinux.org/task/60830 because zeitgeist 1.0 plus 1 commit on master at commit hash (g)1bcc8585, got downgraded to 1.0.1 (which is the same as 1.0+1 but considered lesser due to its not using a commit hash).
Apparently the zeitgeist developers *do* feel fine with changing the number of components in their release versioning.

Thanks, eschwartz.I read the thread about zeitgeist you commented on at the time, and it is very illuminating on how packing methods work...

Arch Linux

#1 2019-01-26 18:46:56

[ Solved ] Packages with long version with "+g" in their names

#2 2019-01-26 19:14:23

Re: [ Solved ] Packages with long version with "+g" in their names

#3 2019-01-26 19:22:27

Re: [ Solved ] Packages with long version with "+g" in their names

#4 2019-01-27 02:14:16

Re: [ Solved ] Packages with long version with "+g" in their names

#5 2019-01-27 04:12:07

Re: [ Solved ] Packages with long version with "+g" in their names

Board footer