Bug 90558 - RPM 4.1 unable to properly upgrade with relocated packages
Summary: RPM 4.1 unable to properly upgrade with relocated packages
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 8.0
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-05-09 16:37 UTC by Mark Hatle
Modified: 2007-04-18 16:53 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-09-01 16:47:21 UTC
Embargoed:


Attachments (Terms of Use)
rpm -vv output of an -U (181.24 KB, text/plain)
2003-05-09 16:38 UTC, Mark Hatle
no flags Details

Description Mark Hatle 2003-05-09 16:37:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.3) Gecko/20030313

Description of problem:
JBJ asked me to enter the following information.  This was generated with the
MontaVista version of RPM which I have already provided to JBJ.

The issue is when upgrading a relocated package with a newer version (same
relocation prefix on the new package), RPM seems to delete the files installed
as part of that package, and the RPM database says the system has the newer version.

Version-Release number of selected component (if applicable):
rpm-4.1 + patches

How reproducible:
Always

Steps to Reproduce:
1.rpm -i --prefix=<something> <package capable of being relocated>
2.rpm -U --prefix=<something> <updated package>
3.rpm -q <package> returns the new version strip

    

Actual Results:  The files that were to be upgraded were gone.

Expected Results:  Upgrade should have put new versions of the files on the system

Additional info:

Comment 1 Mark Hatle 2003-05-09 16:38:15 UTC
Created attachment 91589 [details]
rpm -vv output of an -U

Comment 2 Jeff Johnson 2003-05-10 00:15:52 UTC
Hmmm, you've modified the relocation code. I'll take a look
soonish ...

You're gonna need to do relocations on the header
twice, once when package is added to transaction,
again when installing. Otherwise, the generation
of fingerprints (which is essential for correct
file resolutions to be computed for upgrades) is
gonna break.

Look for the action "skip" after the "fini" diagnostic
message during package erasure.

Comment 3 Jeff Johnson 2003-09-01 16:47:21 UTC
This problem resolved, I believe.


Note You need to log in before you can comment on or make changes to this bug.