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

Re: rpmvercmp is kinda broken, always has been

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.

Maybe at least the "number is greater that alpha" patch should be applied?

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

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.

> 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.


Attachment: pgp00000.pgp
Description: PGP signature

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