Bug 117419 - rpm Upgrade combined with --prefix fails
rpm Upgrade combined with --prefix fails
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-03 15:20 EST by Frederik Holst
Modified: 2007-04-18 13:03 EDT (History)
1 user (show)

See Also:
Fixed In Version: rpm-4.2.1-0.30
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-28 18:35:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Frederik Holst 2004-03-03 15:20:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)

Description of problem:
If a relocatable rpm package is created and is used to upgrade a 
previous version of this package, the upgrade process will delete the 
files to be upgraded if they existed before.
It seems that the new file is first installed at the correct, 
relocated position given by prefix. But then it is deleted because 
rpm compares the new file with a non-existent old file at the path 
position given by the spec file's %files section and therby ignoring 
the given --prefix.

It works if no prefix is given or if the upgrade rpm command is 
issued twice (because then there is no file to delete anymore). But 
this can't be a workaround because certain %post commands may only be 
issued once.

Version-Release number of selected component (if applicable):
rpm-4.1.1-71

How reproducible:
Always

Steps to Reproduce:
1. Generate a relocatable rpm and install with --prefix given.
2. Generate a newer version of this rpm including the same file(s) in 
a newer version
3. Install with rpm -U --prefix. 

Actual Results:  The files that existed before will be removed, those 
not existing before will be correctly installed.

Expected Results:  The files that existed at the given --prefix 
should be upgraded.

Additional info:
Comment 1 Jeff Johnson 2004-03-19 06:33:03 EST
Do you have a copy of the srpm you used, and a list of
exactly the commands executed and an explicit list of
the (presumably) files that were not removed?
Comment 2 Jeff Johnson 2004-03-19 06:34:21 EST
copy of the srpm that produced the binary rpm's which
did not upgrade is what I meant. Sorry for any confusion.
Comment 3 Frederik Holst 2004-03-19 11:07:45 EST
It's just a simple rpm that only contains files, no compiling or 
anything. Here is a short example:

master.spec:

---

# Test Spec Master

Name:           Test
Version:        0.0.1
Release:        1
Group:          Application/Networking
License:        GPL
Prefix:         /tmp/test
Summary:        Test Master

%description
Test Master

%prep
mkdir -p /tmp/test
cp /etc/inittab /tmp/test

%files
/tmp/test/inittab

---

This takes the /etc/inittab (or any other file) and puts it into the 
rpm:
rpmbuild -bb master.spec
Install this new rpm with the following:
rpm -i --prefix=/tmp/test2 Test-0.0.1-1.i586
You will find the inittab in /tmp/test2/inittab.
So far, so good.

Now take this update.spec which provides the previous rpm with a "new 
version":

update.spec:

---

# Test Spec Master

Name:           Test
Version:        0.0.2
Release:        1
Group:          Application/Networking
License:        GPL
Prefix:         /tmp/test
Summary:        Test Update

%description
Test Update

%prep
echo "New inittab" > /tmp/test/inittab

%files
/tmp/test/inittab

---

This creates a new inittab and puts it into a new rpm:
rpmbuild -bb update.spec
Install it now with Upgrade and Prefix:

rpm -U --prefix=/tmp/test2 Test-0.0.2-1.i586.rpm

The result is, that there will be no inittab file anymore 
in /tmp/test2. Neither the old one, nor the new one.

If you do all installations without the --prefix, all works fine.
Comment 4 Leonard den Ottolander 2004-03-19 11:59:07 EST
Verified this on RHL 9, rpm-4.2-0.69. Indeed the file disappears.

However, on Fedora Core 1, rpm-4.2.1-0.30 this works fine.

So either you can backport the fix from FC 1 to RHL 9, or close this
as CURRENTRELEASE.
Comment 5 Paul Nasrat 2005-11-28 18:35:01 EST
Thanks for the testing.

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