Re: problem comparing capability version strings

"Jeff Johnson" <[email protected]> Sat, 19 Apr 2008 15:30:08 -0400
Newsgroups gmane.linux.redhat.rpm.general
Message-ID <[email protected]>
On Wed, Apr 9, 2008 at 10:11 PM, Dave Peterson <[email protected]>
wrote:

>
> To see if the GConf2 capability provided by B satisfies A's
> requirement, I call rpmvercmp() as follows:
>
>   int result = rpmvercmp("2.14.0", "2.14.0-9.el5");
>

The problem is likely conceptual.

rpmvercmp compares strings according to rpm's comparison rules.

However rpm uses the triple {Epoch,Version,Release} to determine newer.

That means that rpmvercmp is called multiple times (Epoch is always a digit
string,
strcmp on zero-padded strings is used for infinite precision, but the
comparison
rules for digit-only strings do not need to use rpmvercmp). rpmvervmp is
definitely
called for each of Version and Release.

Your example is comparing a Version "2.14.0" with a Version-Release
"2.14.0-9.el5".

That needs to be done by splitting on the '-' in "2.14.0-9.el5" and calling
rpmvercmp
twice.

You are still likely to be surprised by the results.

rpmvercmp basically tries to compare alphas with alphas, and digits with
digits,
because originally (before YYYYMMDDhhmmss digit strings were noticed to
exceed 32 bits) compared by converting to ints.

That's the sensible part.

The scwewy part(s) of rpmvercmp include the following:
   1) leading 0's are ignored. e.g. 5.000000000003 is greater than 5.2
because 3 > 2
   2) all punctuation is ignored and treated as equivalent. so 5.2 and 5_2
are equal.
and (finally, this is the one that you will be surprised at)
  3) mixed mode (as in digit string compared to something other than digit
string) is reversed
  from the comparison order one would expect. But its very hard to expect a
result from
   a comparison between something and nothing, consider what happens to
strcmp
   if fed NULL or "", two forms of expressing nothing.

All well known flaws, been there forever, nothing can be done without
coordinating the
change, which is bloody unlikely to happen.

hth

73 de Jeff

_______________________________________________
Rpm-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rpm-list