[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 11:49:58AM -0500, Jeff Johnson wrote:
> 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

But this doesn't fix the problem with non-antisymmetric ordering
operator. This should be fixed as foo-1.2.a and foo-1.2.1 are currently both
newer than the other. From your notes:

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

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

But it fixes the ordering properties. Currently rpm allows for
"toggle-updates" between foo-1.2.a and foo-1.2.1 (BTW thanks to Warren Togami,
who recently rediscovered this bug), and the same is true for other rpm
managing systems like up2date and apt-get, if they use the same version
comparison code (don't know, if they actually do, don't pin me on that, OTOH
any rpm managing software should use the same ordering algorithm as rpm, even
if it is broken).

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

Just consider the following scenario: A Red Hat release provides packages
without mp3 support. Then Matthias Saou provides some of the packages with mp3
support replacing the release number tag with one beginning with an alpha
segment, e.g. -fr1. If epoch and version are the same you have two packages
which cannot be compared. This has almost happened with RH80 and could very
well happen with RH81. Taking the rising user contributed support to rpms into
account this problem becomes bigger.

I just say, that it is better to try to fix it now, before it becomes even
more messy. Removing the above ambiguity couldn't break anything more than is
already broken.

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

On Fri, Jan 03, 2003 at 11:36:28AM -0600, Chris Garrigues wrote:
> > On Fri, Jan 03, 2003 at 11:49:58AM -0500, Jeff Johnson wrote:
> > > 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 ;-)
> > Nah, modulo 3 doesn't work. Neither do any of
> > bash$ dc
> > 503 2 % p
> > 1
> > [...]
> > 503 53 % p
> > 26
> > ...
> > Looks like 503 is gonna stay bigger than 6 forever, sigh.
> > ;-)

Guess what? You just found a prime number ... ;)

> I noticed in his original email he was actually asking about 00503 being less 
> than 6, not 503.
> Clearly there's a special case that could be defined for version numbers which 
> have leading zeros.

I don't want to "make 503 less than 6", but it is a real life example, if you
compare two rather common perl versions: perl-5.00503 < perl-5.6.0 suggests
either "00503" < "6" or increasing epochs. It is a waste of epochs to have to
use them for enforcing 'foo-1.02 < foo-1.1'. There aren't many such packages:

# rpm -qa | grep '\.0[0-9]'| wc -l

but they have some prominent members apart from perl, like bash (2.05b), sed (3.02)
ghostscript (7.05), quota (3.06) or acroread (5.06).

Making perl-5.00503 < perl-5.6.0 or quota-3.06 < quota-3.1 is an easy matter,
if one decides to, just don't remove the leading zeros in rpmvercmp.

Attachment: pgp00003.pgp
Description: PGP signature

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