[aur-general] Upstream version numbers that break pacman version comparison
Hi, I maintain a package in the AUR [1], coq [2], whose upstream versioning scheme is a bit strange. Basically, they release versions in the following order: 8.4 → 8.4pl1 → 8.4pl2 → 8.5 → 8.5pl1 → etc This breaks pacman's comparison function. For instance, with a local repo, pacman does not consider that the new version 8.5pl3-1 is newer than the old 8.5-1: # pacman -Syu warning: coq: local (8.5-1) is newer than repo (8.5pl3-1) This makes sense given the documented behaviour of pacman(8): When upgrading, pacman performs version comparison to determine which packages need upgrading. This behavior operates as follows: Alphanumeric: 1.0a < 1.0b < 1.0beta < 1.0p < 1.0pre < 1.0rc < 1.0 < 1.0.a < 1.0.1 Numeric: 1 < 1.0 < 1.1 < 1.1.1 < 1.2 < 2.0 < 3.0.0 What is the best solution to deal with this? I think I can either map the scheme to a more reasonable one (e.g. "8.5.pl3" instead of "8.5pl3"), or bump the epoch when needed. Thanks, Baptiste [1] https://aur.archlinux.org/packages/coq/ [2] https://coq.inria.fr/
On 11/22/2016 02:53 AM, Baptiste Jonglez wrote: (SNIP)
What is the best solution to deal with this? I think I can either map the scheme to a more reasonable one (e.g. "8.5.pl3" instead of "8.5pl3"), or bump the epoch when needed.
what i'd recommend is instead use 8.5 -> 8.5.1 -> 8.5.2 and then have a _pkgver= variable with the actual string, if it's needed later in the build. i.e.: ... pkgver=8.5.1 _pkgver=8.5pl1 .. build() { cd ${srcdir}/${pkgname}-${_pkgver} ... or such. i think that may be the cleanest way but i also would like to see input from others.
On 11/22/2016 08:58 AM, brent timothy saner via aur-general wrote:
what i'd recommend is instead use 8.5 -> 8.5.1 -> 8.5.2
and then have a _pkgver= variable with the actual string, if it's needed later in the build. i.e.:
I don't like this because it prevents users from seeing which version they installed with pacman -Qi. Many will want to be able to look up their version online, e.g. for changelogs or security advisories. It's ugly, but I guess bumping epoch is the only solution here. Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
On 11/22/2016 03:07 AM, Bennett Piater wrote:
On 11/22/2016 08:58 AM, brent timothy saner via aur-general wrote:
what i'd recommend is instead use 8.5 -> 8.5.1 -> 8.5.2
and then have a _pkgver= variable with the actual string, if it's needed later in the build. i.e.:
I don't like this because it prevents users from seeing which version they installed with pacman -Qi. Many will want to be able to look up their version online, e.g. for changelogs or security advisories.
It's ugly, but I guess bumping epoch is the only solution here.
Cheers, Bennett
It's worth noting openssh uses the same versioning naming (though i don't see what's so hard to mentally replace the last minor with a p in front). Here's the PKGBUILD: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packag... they don't seem to use epoch. my suspicion, if pacman indeed doesn't recognize the updated version per your claims, is that they bump the pkgrel but CBA to clone the repository and look through the past commits.
On Tue, Nov 22, 2016 at 03:12:58AM -0500, brent timothy saner via aur-general wrote:
It's worth noting openssh uses the same versioning naming (though i don't see what's so hard to mentally replace the last minor with a p in front).
Here's the PKGBUILD:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packag...
Interesting, thanks. However, upstream starts each new minor version at p1, so it looks like: 7.2p1 → 7.2p2 → 7.3p1 → etc which works fine for pacman. The problematic behaviour for pacman would be: 7.2p1 → 7.2p2 → 7.3 → 7.3p1 → etc In the case of coq, I guess this is something that should ideally be fixed upstream. Baptiste
Em novembro 22, 2016 6:35 Baptiste Jonglez escreveu:
Interesting, thanks. However, upstream starts each new minor version at p1, so it looks like:
7.2p1 → 7.2p2 → 7.3p1 → etc
Worth nothing that OpenSSH releases the so called "portable" versions. Hence the 'p'.
which works fine for pacman. The problematic behaviour for pacman would be:
7.2p1 → 7.2p2 → 7.3 → 7.3p1 → etc
In the case of coq, I guess this is something that should ideally be fixed upstream.
What a horrible, ugly way to version packages. If they could fix it upstream, its better. And it might even benefit other distributions. Otherwise I'd go with the 7.2.p2 scheme. Messing with epoch should be your last resort. Cheers, Giancarlo Razzolini
On Tue, Nov 22, 2016 at 11:28:40AM +0000, Giancarlo Razzolini wrote:
Em novembro 22, 2016 6:35 Baptiste Jonglez escreveu:
Interesting, thanks. However, upstream starts each new minor version at p1, so it looks like:
7.2p1 → 7.2p2 → 7.3p1 → etc
Worth nothing that OpenSSH releases the so called "portable" versions. Hence the 'p'.
You're right, it's not the same semantic.
which works fine for pacman. The problematic behaviour for pacman would be:
7.2p1 → 7.2p2 → 7.3 → 7.3p1 → etc
In the case of coq, I guess this is something that should ideally be fixed upstream.
What a horrible, ugly way to version packages. If they could fix it upstream, its better. And it might even benefit other distributions.
Totally agreed. I reported the bug upstream [1], and it turns out the maintainers have already planned a more reasonable versioning scheme for the next version. So, problem (most likely) solved! Thanks, Baptiste [1] https://coq.inria.fr/bugs/show_bug.cgi?id=5221
I'm not usually saving mails from here. After a thread is finished, I delete It. But this will be useful for the future if someday I have to maintain a package with such an ugly versioning scheme like this.
On Tue, Nov 22, 2016 at 7:53 AM, Baptiste Jonglez < baptiste@bitsofnetworks.org> wrote:
What is the best solution to deal with this? I think I can either map the scheme to a more reasonable one (e.g. "8.5.pl3" instead of "8.5pl3"), or bump the epoch when needed.
I would go with the 8.5.pl3 scheme. Keeps the version info, and it's not much different from what actually is upstream.
participants (6)
-
Baptiste Jonglez
-
Bennett Piater
-
brent timothy saner
-
Carlos Silva
-
Giancarlo Razzolini
-
Juan Martínez