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

Re: rpmvercmp is kinda broken, always has been

On Fri, 2003-01-03 at 16:01, Jeff Johnson wrote:
> On Fri, Jan 03, 2003 at 08:21:01PM +0100, Axel Thimm wrote:
> > 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).
> 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.
> 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.
> > 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.

I would be happy to gather a list of all the EVRs from all released RHL
versions from 6.2 to current, along with as many errata versions as I
can find.  Using this list I can fairly quickly find the pairs that
would be effected by the change in my patch #60884.

As I have frequently mentioned before, I would like to see 50977 get
fixed.  When I opened the bug I only intended to cover one thing -- the
non-transitive nature of the current algorithm in one corner case.  I
would like nothing more than to have that fixed and close 50977 so
people can stop confusing this issue with other issues.

> > > > Also the "00503" > "6" problem would be nice to be fixed, too.
> 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.

I am going to go on the record that I am strongly opposed to "fixing"
this.  These are the exact cases epochs were invented to handle.  Having
dealt with thousands of packages from many different vendors, changing
anything beyond the minimal amount necessary to fix 50977 will break too
many things.  See some of my earlier (bad) ideas in 50977 for why any
change is bad.


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