Description of problem:
RPM's version comparison is not symmetric, that is rpmvercmp(a,b) is not always
equal to -rpmvercmp(b,a).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Compile and run the attached sample:
1. gcc -lrpm -o rpmcomp rpmcomp.c
rpmvercmp ("+", "_") == -1
rpmvercmp ("_", "+") == -1
One of the results should be 1 and the other -1.
Please note that both "+" and "_" are valid RPM versions, as rpmbuild accepts
them both as the "Version:" field.
Created attachment 123615 [details]
Test C code that shows the problem
Yep. There are many problems with rpmvercmp, all known.
WONTFIX in the sense that the fix is worse than living with existing.
Wow! Never hit that corner case. I don't have the code handy, but I'm pretty
sure that the concept of strings that only have segment delimiters isn't
handled. To verify, please try to following tests:
rpmvercmp ("a", "a")
rpmvercmp ("a+", "a_")
rpmvercmp ("+a", "_a")
rpmvercmp ("+_", "+_")
I will try to look at the code today; I'm on a plane overnight, so I should have
some hacking time.
After a little testing, the issue shows up for cases other than strings
containing only non-alnum chars. It actually impacts string where the final
segment is null. This means that comparing "4.1__" and "4.1+" is currently buggy.
It is a one line fix to resolve this issue. We really should put some bounds on
acceptable values for version and release, but that is an issue for a different bug.
Created attachment 124302 [details]
Fix to handle trailing null segments
This patch resolves the issue, and changes comments a little later in the
function to make the workings of rpmvercmp clearer.
Confirming that the patch fixes the problem, and also the extended problem of
when the string string ends in non-alphanumeric chars.
I guess I have also proved that this patch makes rpmvercmp antisymmetric, that
is rpmvercmp(x,y)==-rpmvercmp(y,x), the way it's supposed to be.
Added to rpm CVS, should be in rpm-4.4.5-0.11 when built.