Add rpm-sort utility for sorting RPM versions

[frozencemetery]

rpm-sort(8) is intended for use in shell scripts. sort(1) is not RPM versioning-aware, and attempting to work around that is fraught. Instead, provide a wrapper around rpmvercmp() using qsort().

Fedora's grub2 has carried a version of this since 2015, and a more complex version was also part of the grubby project (provided at /usr/libexec/grubby/rpm-sort) since 2018. This version has been simplified and adapted to the RPM project.

Also-authored-by: Peter Jones [email protected]
Signed-off-by: Peter Jones [email protected]
Signed-off-by: Robbie Harwood [email protected]

[Code is ready for inclusion.

While rpmdevtools does provide a rpmdev-vercmp utility, it is limited to comparing two versions at once only, meaning shell scripts would need to reimplement the sorting logic. It's also not typically installed on end-user systems, so we couldn't use it from grub2/grubby.]

[frozencemetery]

(CI was broken with 190354c, hence the revert commit.)

[pmatilai]

I can see how grub* needs such a thing, but I don't really see why this should be in rpm itself. It's not a particularly common use-case AFAICS.

[DemiMarie]

I can see how grub* needs such a thing, but I don't really see why this should be in rpm itself. It's not a particularly common use-case AFAICS.

I had to hand-roll something similar when figuring out which was the most recent VM kernel package I had installed in my dom0.

[pmatilai]

Yeah there are use-cases, such as figuring out the order of stuff in a directory. Still, not convinced this needs to be in rpm.

But assuming for a moment we were to merge this, there are some issues to sort (pun not intended) out:

• this belongs to tools/ rather than the top-level directory
• drop the revert commit (ci breakage should be reported, not reverted, its now fixed anyway)
• rpm tools do not have dash in the name, eg it should be called 'rpmsort'
• use of alloca() is prohibited
• it should use rstrndup() rather than manual malloc+strncpy, possibly other cases where rpm has string helpers
• rpmvercmp() on package name seems dubious, the name does not take part in version comparison and rpmvercmp() is known to return 0 for very obviously different strings

[frozencemetery]

Thanks for the review; updated.

It's not a particularly common use-case AFAICS.

Well, depends on how you define "common", I suppose - it gets called every time a new kernel is installed, which is pretty common :)

Still, not convinced this needs to be in rpm.

I'm not seeing a better place for it - are you?

It doesn't belong in grub or kernel-install because adding a build dependency on RPM doesn't make sense upstream. It doesn't belong in rpmdevtools because it needs to be installed on every system and that isn't. Pretty much all it does is provide a shell interface to a function from librpm.

Looking at other systems for precendent, a tool like this generally isn't needed because sort -V is good enough - e.g., on Debian. Even so, the comparison functionality at least is exposed by the core tool (dpkg --compare-versions).

[pmatilai]

Yes it happens a lot, in one highly specific corner. Which is often best served by having that specific corner handle it because it has its own wrinkles that do not apply elsewhere, like version comparing the name here.

In principle, Debian versioning isn't that different from rpm. If 'sort -V' is good enough (if not perfect) for them then it should be close enough for government work for us too. Not that I have looked at the details, maybe the details differ more than it seems on the outset.

Note that in rpm >= 4.16 you can also perform version comparisons from the cli with boolean expressions, eg

[pmatilai🎩︎localhost ~]$ rpm --eval '%[v"1.0-1" < v"2.0-1"]'
1
[pmatilai🎩︎localhost ~]$ rpm --eval '%[v"3.0-1" < v"2.0-1"]'
0

[Conan-Kudo]

@frozencemetery Can you change Also-authored-by to Co-authored-by? The latter is the generally recognized "magic tag" by Git commit processing automation.

[Conan-Kudo]

Yes it happens a lot, in one highly specific corner. Which is often best served by having that specific corner handle it because it has its own wrinkles that do not apply elsewhere, like version comparing the name here.

In principle, Debian versioning isn't that different from rpm. If 'sort -V' is good enough (if not perfect) for them then it should be close enough for government work for us too. Not that I have looked at the details, maybe the details differ more than it seems on the outset.

It works accidentally. If ~ is used, it doesn't sort downward (which dpkg and rpm support). And of course, rpm has ^ now, which sort -V definitely doesn't know.

I'd rather have an rpmsort that I could call directly...

[ffesti]

Could not quite bring myself to just say no.