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

Re: File relocation/dupe file checking

On Fri, Jan 24, 2003 at 10:52:04PM -0600, Mark Hatle wrote:
> I believe I have found a bug in rpm 4.1/4.2(cvs).  Basically we use RPM's 
> relocation to install all of our rpms.  (basically by using "--prefix=/".  Yes, 
> it may sound silly to you but we have our reasons, and not doing that isn't an 
> option.)

Hmmm, there are sorts of special cases associated with --prefix=/, so you're
asking for trouble, and have probably found some.

> Ok..  the behavior I am seeing is I can do an:
> rpm -i <package>-1-1.arch.rpm
> then immediatly after do:
> rpm -i <package>-1-2.arch.rpm
> and RPM happily installs both and I now have two entries in teh database for the 
> same package (different RPM release number)..  But of course all of the files 
> SHOULD have conflicted.

No, rpm has some subtle differences between -i and -U, no file conflicts
being one. Because it's an install, not an upgrade, any file paths will
be silently replaced, but the state of the earlier installed file will be
changed from NORMAL to REPLACED.

Why aren't you using -U? If you're trying to install multiple, but relocated,
versions of the same package, you are most assuredly blazing trails through
rpm code paths.

> First question (I havn't attempted to track down an answer for this) why is rpm 
> not complaining a version of that package already exists in the system and 
> stopping the install?  (I thought this was previous RPM behavior.)
> Now the second question, why is it not identifying the conflicting files and 
> stopping at that point.. This one I have spent considerable time tracking down. 

Because -i is different than -U. I can dig out details if necessary.

>   And this is where I believe the main problem is.
> Ok.. then:
> After computing the fingerprints in lib/transactions.c, it gets to 
> fpLookupList(...), which eventually calls into "doLookup(...)" in rpmdb/fprint.c
> In doLookup the paths it recieves are the full PRE relocation paths.  It then 
> attempts to find out what is a "real-on-disk" path and works its way down from 
> the full path to a minimal path..  example:
> rpm contains:
> /opt/mvlcge/devkit/x86/pentium3/target/bin/bash
> Relocation prefix is:
> /opt/mvlcge/devkit/x86/pentium3/target
> w/ --prefix=/ that results in:
> "//bin/bash"  (Yes, I have verified there is a "//" stored in the rpmdb and 
> such, which is of course a non-defined POSIX path, but it works w/o problems on 
> Linux...)

Hmmm, there's a call to rpmCleanPath() that needs to be added somewhere deep in
the relocate code.

> Now when we get into the doLookup function it starts w/:
> /opt/mvlcge/devkit/x86/pentium3/target/bin attempts to "stat" that, and of 
> course fails since that doesn't exist on the disk..
> then it trys "/opt/mvlcge/devkit/x86/pentium3/target" stats that and it doesn't 
> exist.. repeats that until it gets down to "/opt"
> This is then subtracted from the original path to return back 
> "mvlcge/devkit/x86/pentium3/target/bin/"
> (process repeats for all of the files)
> It then does it again, but this time based on what is in the rpm database.  So 
> it gets:
> //bin
> Since /bin "stats", then then takes 'bin' off of the path name and returns NULL 
> since "/" is supposed to equal NULL.

Yup, broken if "//" is my guess.

(aside) There's another buglet with top level directories like /bin in the
fingerprint code, I've forgotten details, but you may be exercising that

> Later on in rpmdbFindFpList it eventually does a comparison between the rpmdb 
> and the list just created.. and eventually does a comparison between NULL and 
> "mvlcge/devkit/x86/pentium3/target/bin" which fails.. This failure says that the 
> file does not already exist on the disk so there are no conflicts.
> Now, if we flip it around a bit and do a "normal" rpm (w/o the relocation) of 
> say "/bin/bash"..  then it compares NULL to NULL and again says that there are 
> no conflicts.. :P
> So in otherwords, I believe that it is searching the wrong path components, and 
> secondarily if it was searching the right path components then without dealing 
> with the relocation path it still will never correctly fail.

Maybe. THe fingerprint code is very, very arcane, I cannot hazard a guess.

> So the million dollar question for me..  Why is it going through all of those 
> steps in doLookup?  why not just do a simple compare and no stat?  And second (1 
> cent question) how do I get it to honor the relocation?

All the steps in the fingerprint code are necessary to disambiguate symlinks
in directory paths.

Simple compares fail if there are symlinks, FP_EQUAL does not.

So backup here and tell me what you are really trying to do. Using -i,
not -U, has some subtle effects, and insisting on --prefix=/ is asking
for trouble.

What are you trying to do?

73 de Jeff

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

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