Re: Mandrake rpms and sorting order

[Jeff Johnson <jbj JBJ ORG>]

On Fri, Mar 09, 2001 at 06:31:39PM -0500, Vladimir Vukicevic wrote:
> Does anyone on this list have any insight into how Mandrake sorts their
> rpm version numbers?  The behaviour I'm seeing right now is the
> following... with two packages, say,
> 
> ghostscript-5.50-35mdk.i586.rpm
> ghostscript-5.50-35.1mdk.i586.rpm
> 
> Doing a vercmp() straight from librpm on those two versions gives:
> 
> vladimir@rain[1012]% zz 'ghostscript-53.5-10.1mdk'
> 'ghostscript-53.5-10mdk'
> result: -1
> 
> ... which would indicate that the 10.1mdk package is less than the 10mdk
> package, which is not the order that Mandrake sorts these in.  When I
> attempted to install the 10.1mdk package over the 10mdk package using
> --justdb --nodeps to see if rpm 3.0.5 stock would give an error message,
> rpm 3.0.5 was killed by the kernel due to an out of memory condition.
> An strace showed an infinite loop of lseek(fd, #, SEEK_SET) read()
> brk(), with the # being the same each time. Note that if I try to just
> install the 10.1mdk package by itself, it goes in fine (so there is no
> package corruption going on). Of course, on a Mandrake system, this
> works fine.
> 

This is a broken chain in the first-fit file packages.rpm managed by
lib/falloc.c. The symptom shows up either as
	Free list corrupt
if you happen to find end-of-chain, or as a nasty loop if the chain
reconnects to itself.

The problem has been in rpm for years, is/was the motivation for changing
to db3.

> Examining the Mandrake-patched rpm 3.0.5 didn't reveal any patches to
> rpmvercmp() nor any overriding of the oldpackage problem filter...
> 

rpmvercmp may be returning -1 where it should be returning +1, bugzilla #21392.

73 de Jeff

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