appstream-glib
appstream-glib copied to clipboard
Wrong version comparaison is some situations
Hello,
It seems that appstream is being confused with plus (+) in version numbers:
$ appstream-util vercmp 2:2.9+git20200213+877d9a0-1 2:2.9-6
2:2.9+git20200213+877d9a0-1 < 2:2.9-6
2:2.9+git20200213+877d9a0-1 is strictly bigger than 2:2.9-6 at least with debian conventions
This impacts gnome-software
FWIW, I don't think 2:2.9+git20200213+877d9a0-1 is something we should ever show the user.
Here’s a reference for how Debian version numbers are defined and should be compared: https://manpages.debian.org/unstable/dpkg-dev/deb-version.5.en.html
FWIW, I don't think
2:2.9+git20200213+877d9a0-1is something we should ever show the user.
I don’t think that’s relevant here. It’s pretty rare that Debian packages have such versions, and if you’re going to hide it, what are you going to show instead? If version numbers are going to be shown in gnome-software at all, I think this one should be no different.
I updated the link to the gnome-software bug report, but it seems that arch is also impacted, not only debian
Hi, You may have a look here: https://github.com/ximion/appstream/issues/288 Mainly my remark about the gnome-software package dependency in Debian because I was confuse to address the same issue saw using GNOME Software.
@pwithnall An argument could be made though to strip the epoch (2:) from such version numbers when they are displayed. As for everything else, I agree - either all version numbers, or none :-)
I am surprised that AppStream also has the same bug, as its version comparison algorithm is radically different to the one in appstream-glib (it's actually derived from RPM's) and I would have expected the RPM algorithm to also handle plus signs well - but apparently not ;-) I think I will make a test-tool to actually test the RPM algorithm vs the Debian one, and see if there's a way to come up with one that works for all version numbers used in Fedora as well as Debian (it feels like that's something that should be possible, at least).
Another one bites the dust: microcode_ctl.x86_64: 2:2.1-55.fc38 -> 2:2.1-55.1.fc38 detected as downgrade.