Bug 50977 - version comparisons for packages with numeric and alpha versions don't work
version comparisons for packages with numeric and alpha versions don't work
Product: Red Hat Public Beta
Classification: Retired
Component: rpm (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
: 51333 69342 82639 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2001-08-05 19:07 EDT by Peter Bowen
Modified: 2014-01-21 17:48 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-10 14:53:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch against tip of branch rpm-4_0 in CVS (879 bytes, patch)
2001-08-05 19:08 EDT, Peter Bowen
no flags Details | Diff
2nd try at a patch (1.38 KB, patch)
2001-08-07 00:01 EDT, Peter Bowen
no flags Details | Diff
rpmvercmp background comments (3.22 KB, text/plain)
2001-08-07 09:29 EDT, Jeff Johnson
no flags Details
here is what we are probably going to use in the 8.1 (935 bytes, patch)
2001-09-16 00:54 EDT, Frederic Lepied
no flags Details | Diff
Make rpmvercmp transitive (623 bytes, patch)
2002-06-13 14:18 EDT, Peter Bowen
no flags Details | Diff

  None (edit)
Description Peter Bowen 2001-08-05 19:07:34 EDT
If you have two RPMs with EVRs of 1.0.1-10.7.2 and 1.0.1-10mdk, RPM doesn't
know which is newer.  The rpmvercmp function always returns 1, reguardless
of which order they are passed to it.

Bug #21392 tried to fix this, but is just changed the return value, and
didn't fix the underlying problem.  It used to always return -1, now it
returns 1.

The attached patch will prevent the current ambiguity, and will not break
existing RPM functionality.  With this patch 10.1mdk is still newer than 10mdk.
Comment 1 Peter Bowen 2001-08-05 19:08:34 EDT
Created attachment 26355 [details]
Patch against tip of branch rpm-4_0 in CVS
Comment 2 Peter Bowen 2001-08-06 10:48:53 EDT
Having tested this patch some more, one other thing has shown up: distributions
which start with an alpha string in the release will always loose version
comparisons.  Currently, Mandrake, Connectiva and Scyld use alpha strings
appended on to the release, while Ximian prepends an alpha string to the release.

As an unintended side effect of this patch is that it helps with the issue of
users upgrading from RHL+Ximian GNOME to RH's next release having a mixture of
Red Hat and Ximian RPMS left on their machine.

A couple of examples:

Original         Bug #21392       This patch
--------         ----------       ----------5 < 6            5 < 6            5 < 6
10 > 9           10 > 9           10 > 9
10mdk > 10       10mdk > 10       10mdk > 10

10mdk < 10.1mdk  10mdk > 10.1mdk  10mdk < 10.1mdk
10.1mdk < 10mdk  10.1mdk > 10mdk  10.1mdk > 10mdk

8 < ximian.1     8 > ximian.1     8 > ximian.1
ximian.1 < 8     ximian.1 < 8     ximian.1 < 8

Originally, RPM always returned -1 (less than) when comparing alpha and numeric
values (reguardless of the order).  When the patch from Bug #21392 got applied
to RPM, it always returned 1 (greater than).
Comment 3 Ian Peters 2001-08-06 15:17:57 EDT
(Replying at Jeff's request)

First impressions: the behaviour in your patch is:

a) obviously unacceptable for our current scheme -- as you note, all ximian
packages would then lose version comparisons, making our packages virtually
uninstallable.   We would have to resort to bumping epochs on our packages,
something I can't tell you how much I want to avoid.

b) rather hackish, as what you're essentially doing is implicitly breaking a
single field (version/release) into multiple fields, where 10mdk and 10.1mdk
become "10" "mdk" and "10.1" "mdk" before comparison starts.  (Yes, I realize
this isn't how the code actually does it, but it's semantically identical.)
Realize that your patch is essentially the opposite of something we sent off to
Jeff a while back (and what was applied to our copy of rpmvercmp inside red
carpet), which makes alpha sort higher than numeric (behaviour: ximian.1 > 1
(good), 10mdk > 10.1mdk (bad)).

We fixed the appended alpha problem by stripping these characters off, as they
don't appear to be used for anything other than immediate vendor recognition
(more on this later).  Thus, when confronted with 10mdk and 10.1mdk, we just
stripped the mdk parts first, then compared 10 and 10.1, which works fine.  The
presence of the "mdk", occuring as it does after the rest of the release string,
doesn't really affect the comparison except in a few cases.

Now, I can understand that you might view this as suboptimal.  ;-)


Stop allowing alpha characters in the release, and define appropriate behaviour
for the version.  Vendor information should go in the VENDOR header tag.  This
sucks because it's then unclear how to easily relate packages from different
vendors (not that it's clear at all today).

IE if distribution A ships with foo-1.0-5, and we then ship Ximian GNOME for A,
we would probably have to start our package at release 6 (foo-1.0-6) to ensure
that things correctly installed.  This breaks, of course, if A later ships an
update to foo as foo-1.0-33 (perfectly within their rights and logical if
they've been through 28-some internal releases).

Perhaps it makes sense to allow package dependencies to encode vendor
information without putting this into the release field.  Thus, if we ship
mozilla and nautilus with modifications such that our nautilus packages only
work correctly with our mozilla packages, we could have nautilus require
something like mozilla > {XIMIAN}0.9.1...

I apologize for how long and stream of consciousness this is, but I'm short on
sleep and quite a bit sick.

As to timing, the sooner this gets resolved the better, I think.  I'd love it if
we could all come to some consensus and then work our an appropriate ruleset,
move to whatever new naming scheme is chosen, etc without much trouble.
Comment 4 Glen Foster 2001-08-06 17:49:37 EDT
This defect really needs to be fixed, but there's simply no way to get it done
in time for the next release... thanks for reporting this one, though!
Comment 5 Peter Bowen 2001-08-07 00:01:14 EDT
Created attachment 26553 [details]
2nd try at a patch
Comment 6 Peter Bowen 2001-08-07 00:43:19 EDT
After I found the Ximian issue, I assumed it would not be a satisfactory
solution.  The last thing I want to do is encourage epoch inflation.

I also don't want to create two different rpmvercmp functions - one for versions
and one for revisions.  I think that forcing the release to be only numeric is a
little drastic, and would prevent things like 2.10m, which some programs, such
as util-linux use for version numbers.

The basic premise of the fixes is that the following should be true:
1) if (a = b) then (b =a ) and
2) if (a > b) then (b < a)

Currently, only #1 is guarenteed to be true.  #2 frequently true, but sometimes
(a > b) and (b > a), which causes problems when trying to figure out what to

My 2nd try at a fix uses the fix from 21392, but changes the code that searchs
for the endpoints of the substring.  If the beginning of both substrings are
alpha, the is no change in the logic -- it scans until it finds a non-alpha
char.  However, if _either_ substring begins with a number, it finds the first
numeric substring in each string, and compares those.

So what does this mean to existing packages?  Here are some examples from my
previous table, plus a couple more:

Patch #26553
5 < 6
10 > 9
10mdk > 10  these are all as expected

10mdk < 10.1mdk
10.1mdk > 10mdk  finally, this is correct

8 > ximian.4
ximian.4 < 8  same as the last patch, but hold on

2 < ximian.4
ximian.4 > 2  nifty.  We are only comparing the numbers,
              so it works.

So, as was suggested, add-on/overlay vendors, such as Ximian, VA Linux, and
Scyld would have to make sure that packages shared with a base distribution
started release numbering with the base's release number.  The issue about
errata still exists, however.  For Ximian's packages, if Red Hat had a package
version 1.0.1-5, Ximian would have to start with 1.0.1-ximian.6.

As to the second suggestion, the idea allowing dependencies on RPMTAG_VENDOR, I
will hold off on that.  It should probably get opened as a seperate bug.

I must appologize if this seems like a really bad fix.  I came up with it on the
way home, and I am very tired.  But I agree that it would be good to get this
fixed soon.
Comment 7 Jeff Johnson 2001-08-07 09:28:36 EDT
Adding vendor as part of dependency solving is The Wrong Thing
To Do for open source. There's certainly nothing stopping you
from, say, coloring all ximian packaging with
	Requires: ximian_is_my_vendor
and adding the corresponding Provide" somewhere.

Attached are my comments sent privately, now public.
Comment 8 Jeff Johnson 2001-08-07 09:29:39 EDT
Created attachment 26636 [details]
rpmvercmp background comments
Comment 9 Peter Bowen 2001-08-08 18:43:33 EDT
Jeff, I commend you on your email.  You have done an excellent job of
summarizing the issue.  I hope that this gets brought up on rpm-list soon.

As to the current characters in use, Daniel Veillard gave me a dump of the
unique versions and releases in rpmfind's database.  They are available at
http://www.scyld.com/~pzb/version and http://www.scyld.com/~pzb/release

These character sets for these are very similar:
version uses 0-9a-zA-Z and . _ + - @
release uses 0-9a-zA-Z and . _ + -
Looking at the rpmfind dataset,, @ in version seems to primarily be from failed
configure replacements.  The - was a suprise because it should be disallowed and
the + seems to be rarely used.  

For the new code, I would suggesting using a case-insensitive comparisson
function, but this would probably cause the Oracle guys some problems (Sorry
deviant, gafton, et al).  Additionally, it would be nice to drop + - and @ from
the valid list, which would leave RPM with an effective list of a-z, 0-9, ., and
_ which seem like plenty.  It might even be possible to s/_/./ so that it would
just be letters, numbers, and .  For legacy purposes, + - and @ could be
converted to _ or .

This still doesn't solve the floating point issue, but I don't think there is a
good answer to that, because 2.04.7ac8 is, presumably, equal to 2.4.7ac8, but
10.01 is not equal to 10.1.
Comment 10 Jeff Johnson 2001-08-09 12:12:25 EDT
*** Bug 51333 has been marked as a duplicate of this bug. ***
Comment 11 Jeff Johnson 2001-08-09 12:14:33 EDT
*** Bug 51333 has been marked as a duplicate of this bug. ***
Comment 12 Frederic Lepied 2001-09-16 00:54:12 EDT
Created attachment 31838 [details]
here is what we are probably going to use in the 8.1
Comment 13 Seth Vidal 2002-06-13 09:52:18 EDT
Jeff, in response to your question in the email you attached to this bug, I
think implementing the pain would be best in rpm 4.1.

its a big-ish shift in what rpm does and people with any amount of sense know
things are going to break a little then.

Comment 14 Peter Bowen 2002-06-13 14:16:36 EDT
I tend to agree with Seth.  Now is the right time to change this.  I think that
all parties now agree that numbers should be sorted higher than letters.  We
(Ximian) are using a patch that does this.  I think that it is the One Right
Way, as it ensures, on that distros that append a static string to the release,
such as Mandrake, Conectiva, and PLD, that version compares continue to work as
expected.  This also makes rpmvercmp transitive, which will make many people
happy.  The only dissenter in the past has been Ximian, but we now agree that it
is the Right Thing(TM).
Comment 15 Peter Bowen 2002-06-13 14:18:13 EDT
Created attachment 60884 [details]
Make rpmvercmp transitive
Comment 16 Jeff Johnson 2002-07-22 11:37:02 EDT
*** Bug 69342 has been marked as a duplicate of this bug. ***
Comment 17 Jeff Johnson 2002-07-22 11:37:45 EDT
*** Bug 69342 has been marked as a duplicate of this bug. ***
Comment 18 Aleksey Nogin 2002-07-22 11:44:37 EDT
P.S. it appears that RHN is also using the "non-assimmetric" relation (same as
rpm?) that also causes problem (see dup bug 69342), but up2date somehow is using
something else!
Comment 19 Peter Bowen 2003-01-09 18:01:37 EST
I wrote a testjig to determine the impact of patch 60884.  I tested upgrade and
downgrade senarios for all packages in Red Hat Linux 6.2 through 8.0.  The
testjig code, with the testcases, is available at

The patch in question determines a sort order when comparing an alpha char to a
numeric char.  The numeric char is determined to always sort higher than the
alpha char.

Testing shows that only four packages in RHL have any sort of issue with this
change -- cipe, fileutils, hanterm-xf, and textutils. 

cipe-1.4snap-1.i386.rpm shipped with RHL7.0.  More recent RHL releases
have 1.4.5-{5,6,9,11}.  Upgrades will work as expected, because numbers
are still sorted higher than letters in the modified function.

fileutils 4.0x-3 shipped in RHL7.0, and fileutils 4.0.36-4 shipped in
RHL7.1.  As above, the upgrade will work as expected.

hanterm-xf p19-15 shipped in RHL7.2 and RHL7.3, and hanterm-xf 2.0.0-6
shipped in RHL8.0.  As above, the upgrade will work as expected.

textutils 2.0e-6 shipped in RHL6.2 and textutils 2.0e-8 shipped in
RHL7.0.  In RHL7.1 textutils 2.0.11-7 was shipped.  As above, the
upgrade will work as expected.

All of these will work on upgrade, but, in the past, you could also
"upgrade" back to the version from the previous release without rpm
complaining.  With the patch, you must pass the --oldpackage flag.  I think
that this is what people will expect, as a downgrade should require the
--oldpackage flag.

I hope that patch 60844 can get into RPM 4.2.
Comment 20 Jeff Johnson 2003-01-10 14:53:14 EST
Adding patch #60844 in rpm-4.2-0.55.

Thanks for the help getting this sorted out *finally*.
Comment 21 Jeff Johnson 2003-01-24 10:11:38 EST
*** Bug 82639 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.