[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: rpmvercmp is kinda broken, always has been



On Fri, Jan 03, 2003 at 05:12:46PM +0100, Axel Thimm wrote:
> Hello and happy new one,
> 
> there are more and more rpm repositories created (even I have one ... ;),
> which bring up this old bug in rpmvercmp:
> 
> On Thu, Aug 09, 2001 at 11:27:10AM -0400, Jeff Johnson wrote:
> > On that note, let me put out a RFC regarding a closely related problem,
> > pending changes to rpmvercmp. While there's nothing broken in rpm per se,
> > I believe it's time to simplify some obscure behavior in rpm. This won't be
> > in rpm-4.0.3, but I'm going to try to make any changes as soon thereafter
> > as possible to permit incompatibilities and/or problems to be identified
> > as soon as possible.
> > 
> > Please append comments, concerns, ideas, etc to bugzilla #50977. I suspect
> > that the final resolution for rpm is gonna be to use the version comparison
> > that dpkg uses, as that appears to apply to a larger character domain than
> > that currently used by rpm, but is otherwise entirely compatible.
> 
> I checked rpm's sources, the rpm-list's archives, rpm.org and google and
> didn't find any further development on that matter. I think that this nasty
> bug needs to be fixed now, otherwise all those new rpm repositories will start
> defining their own naming scheme making a future change in rpmvercmp even
> harder to manage.
> 

There's progress on the issue, you just don't know what to look for ;-)

rpm-4.1 now treats a missing/unspecified epoch as Epoch: 0.

See how many package dependencies *still* have problems by doing

bash$ rpm -Vav --nofiles 2>&1 | grep "warning" | wc
    121    1452    8712

> Maybe at least the "number is greater that alpha" patch should be applied?
> https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=60884&action=view

Nope, changing how versions are compared needs more than just a patch applied.

> 
> Also the "00503" > "6" problem would be nice to be fixed, too.
> 

Heh, so you want rpm to make the number 503 less than 6? Well I suppose
I could do the comparison "modulo 3", that would work ;-)

> I suggest to specify a standard naming scheme and ordering algorithm, where
> the naming scheme would yield the same results with the future ordering
> algorithm and the traditional one. Then give some time for possible
> about-to-be-broken naming schemes to adopt and finally switch to the new
> ordering algorithm. The naming scheme should also consider custom override
> mechnisms (currently the only one really working is the append method, which
> is fine IMHO), and also custom rpms to be submitted to vendors (for instance
> reserving the "0" release as "not released by Red Hat", so that custom rpms
> look like foo-1.2-0custom17. Same for Mandrake with "0mdk").
> 
> Does that sound reasonable? I do try to keep this scheme on my repository at
> http://atrpms.physik.fu-berlin.de/ and it seems to work.
> 

All reasonable, but impossible to achieve or enforce. I'm hoping that lsb
might help. Maybe, maybe not.

Meanwhile, the existing scheme is adequate for all known purposes, is
(sufficiently) the same scheme that has been used for years in rpm, even
if a bit Baroque and complicated.

73 de Jeff

> > 73 de Jeff
> > 
> > =============================================================================
> > 
> > I'm gonna have to change rpmvercmp, and probably pretty soon.
> > 
> > Background
> > rpm package management uses a function called rpmvercmp() for
> > all version and release comparisons to determine whether package
> > A is "newer" than package B.
> > 
> > Originally, in rpm-2.5.x, the function was implemented as
> > segmented string compares. Strings were broken into alpha
> > and digital segments, alpha segments were compared using strcmp,
> > digits were converted to int32, and compared as integers.
> > 
> > In ~rpm-3.0, it was notced that the digit string YYYYMMDDhhmmss
> > overflowed 2^32, so the digit comparison was changed to use
> > strcmp on padded digit strings, that works for arbitrary length
> > digit strings.
> > 
> > In bugzilla #21392, it was noticed that mixed-mode (i.e. alpha
> > with digit strings) was not defined. Basically, there were
> > a handful of cases where A was "newer" than B, and B was "newer"
> > than A. No one (except Trond :-) had ever noticed until bugzilla
> > #21292 was reported. So the return code for mixed mode comparison
> > was changed.
> > 
> > Then along came LSB, with the goal of unified package management.
> > As part of the discussion, Jason Gunthorpe pointed out that
> > rpm has a very limited character set, only isalnum(3) characters
> > are compared. Surprise, all those '.' charcters are never, ever,
> > used directly by rpm, are only used to demarcate segment boundaries.
> > 
> > Next came ximian with a patch, more or less correct, but with
> > the unfortunate side effect that it broke all of Mandrake style
> > naming. I made up a story (true!) about why I couldn't accept
> > the patch because it broke Mandrake style naming.
> > 
> > Then along came Cristian with some obscure need to convert versions
> > to floats in order to speed up Oracle accesses by RHN. He pointed
> > out that, for rpm purposes,
> > 	1.1 == 1.0000000000000000000000000000000000000000001
> > Ugh.
> > 
> > Now the problem has been outed yet again in bugzilla #50977, with the
> > most correct (but still broken IMHO) patch yet.
> > 
> > Goal
> > ====
> > The criteria for an acceptable rpmvercmp are clear. For package ordering,
> > rpmvercmp needs the same properties as tsort needs (Knuth v1 p258 if it matters)
> > 	1) Transitivity.
> > 	2) Antisymmetry.
> > 	3) Reflexivity.
> > For partitioning transactions into subsets (aka equivalence classes, Knuth
> > v1 p353)
> > 	1) Transitivity.
> > 	2) Symmetry.
> > 	3) Reflexivity.
> > While the current rpmvercmp (almost) has all those properties, this is
> > achieved over too narrow a domain (alphas/digits), and with the added
> > thinko that the '\0' character is (at the moment) treated as an alpha
> > (read: in mixed mode comparison, an explicit digit string is surprisingly
> > less than an implictly empty alpha string. Got that? :-)
> > 
> > So, sometime soon, I'm gonna do the following:
> > 
> > 1) Explicitly restrict the character set permitted in version and
> > release. At the moment, only '-' is denied, and that is far too permissive.
> > I have ~20000 unique version/release strings from RHN that will be used
> > to establish what is existing practice, and the permitted character set
> > will be chosen to minimize breakage.
> > 
> > 2) The existing upgrade universes (i.e. 5.2 -> 6.2 -> 7.0 -> ...) will be
> > examined with current/new rpmvercmp looking for breakage. I point out that
> > this works only for the Red Hat distro universe.
> > 
> 
> -- 
> Axel.Thimm@physik.fu-berlin.de



-- 
Jeff Johnson	ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []