rpmvercmp() compares as equal versions that are not the same

[martinezjavier]

There are cases when the rpmvercmp() function compares two different version strings as equal.

For example, in some cases adding a plus + character at the end of the version denotes that this version is the base version plus some changes. This is the case of the Linux kernel build system where the since the setlocalversion scripts appends a + if the CONFIG_LOCALVERSION_AUTO option is not enabled.

Then if two options are compared using the rpmvercmp() function, it will wrongly do rpmvercmp("5.3.0","5.3.0+") == 0 even when the versions are not the same.

The Fedora GRUB sorts the boot entries using the same algorithm than rpmvercmp(), so a locally built kernel will not appear in the boot menu due the comparing function thinking that this entry is already present, i.e: https://bugzilla.redhat.com/show_bug.cgi?id=1767395

It seems this is not the only case since in PR #597 that added support for sorting ^ higher than base version, a user commented that + should also be supported.

An RFC pull-request fixing the specific case of + is #924. But this is just a special case of a more generic problem.

[pmatilai]

Yup. Other variants of the generic issue include eg 1.0α == 1.0β which also totally defies common sense.

[ffesti]

We really need something better here. But the version comparison is not something that can be changed easily. We might postpone this to the next major release (probably 6.0.0).

Having some fleshed out ideas how the new version comparison should work will still help.
May be we want to have a set of dedicated separators like ".", "-" and ":" and treat anything else as strings that are compared alphabetically.