[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: rpmvercmp is kinda broken, always has been
- From: Jeff Johnson <jbj redhat com>
- To: rpm-list redhat com
- Subject: Re: rpmvercmp is kinda broken, always has been
- Date: Fri, 3 Jan 2003 16:01:39 -0500
On Fri, Jan 03, 2003 at 08:21:01PM +0100, Axel Thimm wrote:
> 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:
Yes, it doesn't.
> > > > 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).
OK, so you *really* want bugzilla #50977 (iirc) fixed.
What's going to be needed first is idetification of actual, not potential
breakage in already deployed packages. FWIW I've heard of maybe 3 actual bug
reports *ever* on the transitivity issue.
A short calculation using Red Hat distros gives me
6 current distros (6.2, 7.0, 7.1, 7.2, 7.3, 8.0)
2000 packages each (ball park figure)
to be a universe of ~12000 package name/epoch/version/release tuples.
That comes out to a crude estimated incidence of ~0.0250%. That's an awfully
small number, too small for me to justify the disruption involved by changing
how rpm compares versions.
Yes, the above estimate is deeply flawed (but conservatively extremely
generous). In fact, I don't believe that the incidence rate is anywhere
near 0.025%, once you factor in that only certain choices of package
epoch/version/release are ever encountered on upgrade.
Even if there are, say, very generously, 50 upgrade choices that fail to
configrm, the failure mode is that each package is newer than the other,
so the package is installed no matter what.
So what is needed is to document the breakage sufficiently so that I can
justify the disruption that changing the manner in which rpm compares
versions will cause.
> > 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.
Reality, please, not hypothetical cases. There's any number of naming schemes
that Mathias Saou could choose in order to avoid a known problem.
> 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.
I'd love to remove the ambiguity, but I don't wish to waste the next
2 years of my life explaining the issue ad nauseum either.
> > > 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.
So you appear to have experience with possibly 3 (perl is a different problem,
already fixed with an Epoch:) upgrade cases. Good, document the cases in
bugzilla so that I can justify the disruption that a "fix" will certainly cause.
73 de Jeff
Jeff Johnson ARS N3NPQ
Chapel Hill, NC
[Date Prev][Date Next] [Thread Prev][Thread Next]