Bug 247749 - rpm -e for multiple architecture packages removes common files
Summary: rpm -e for multiple architecture packages removes common files
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 7
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 248884 251345 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-07-11 08:58 UTC by Piergiorgio Sartor
Modified: 2007-11-30 22:12 UTC (History)
4 users (show)

Fixed In Version: 4.4.2.1-1.fc7
Clone Of:
Environment:
Last Closed: 2007-08-27 21:47:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Piergiorgio Sartor 2007-07-11 08:58:03 UTC
Description of problem:
A multiple architecture system, like x86_64 or ppc64, might have identical
packages for the different architectures. For example pckg-1.2-3.fc7.i386.rpm
and pckg-1.2-3.fc7.x86_64.rpm
In the action of removing the package from one and only one architecture, some
common files, usually in /usr/share/doc/... are removed for both architectures.

Version-Release number of selected component (if applicable):
rpm-4.4.2-46.fc7

How reproducible:
Always, if there are common files

Steps to Reproduce:
1.
Install a package which is provided in two (or more?) architectures, with yum
for sake of simplicity:

yum install pckg

This should provide both pckg.i386 and pckg.x86_64

2.
Remove one package for one architecture:

rpm -e pckg-1.2-3.fc7.i386

3.
Check the remaining one:

rpm -qV pckg

Actual results:
Often, some missing files are reported.

Expected results:
The verification (as above) should return more or less no problems.

Additional info:
This issue was confirmed with a i386/x86_64 system and with a ppc/ppc64 one.
Of course, the point here is to be able to "clean up" such system removing
unused packages.

Comment 1 Panu Matilainen 2007-07-11 09:08:14 UTC
Dupe of #140055, only that's against FC6.

This has already been fixed in rawhide, but leaving open to track the status for
F7 (rpm 4.4.2.1 is planned for F7 as an update)

Comment 2 Michel Alexandre Salim 2007-07-28 12:22:13 UTC
I would like to note that this problem affects single-architecture systems as
well, because some packages do not tag their documentation directories with the
release number.

Should the priority of this be bumped? (Probably academic if an update is
already forthcoming for F7). Also, will this be backported to FC6 as well?

Comment 3 Panu Matilainen 2007-08-13 05:54:18 UTC
*** Bug 248884 has been marked as a duplicate of this bug. ***

Comment 4 Panu Matilainen 2007-08-13 06:09:09 UTC
*** Bug 251345 has been marked as a duplicate of this bug. ***

Comment 5 Fedora Update System 2007-08-13 17:03:07 UTC
rpm-4.4.2.1-1.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.

Comment 6 Piergiorgio Sartor 2007-08-16 20:03:17 UTC
I just installed the new rpm (and dependencies) from update/testing and, after
some trial, it seems it fixes this issue.
I guess the bug could be closed.
Thanks.

Comment 7 Michal Jaegermann 2007-08-18 20:06:34 UTC
> I guess the bug could be closed.

I am not entirely sure about that.  It looks to me that the bug in general
is "rpm removes files/directories which still belong to another package"
and that other package may, or may not, be of a different architecture.
This happens as well during a cleanup of duplicate packages and those
may show up as results of assorted problems in updates.

I just tried with rpm-4.4.2.1-8.fc8 on my test installation. I forced
duplicate packages 'icedax-1.1.6-1.fc8' and 'icedax-1.1.6-2.fc8'
(both x86_64 arch).  After 'package-cleanup --cleandupes' I got:

# ls $( rpm -ql icedax ) >/dev/null
ls: cannot access /usr/bin/cdda2mp3: No such file or directory
ls: cannot access /usr/bin/icedax: No such file or directory

Interestingly enough 'rpm -V icedax' does not report these two
files as missing ( but 'rpm -qs icedax' marks those as "replaced").

OTOH, if I will do the following (which likely better simulates
situations you may encounter in practice):

   rpm -ivh --force icedax-1.1.6-1.fc8.x86_64.rpm
   rpm -ivh --force icedax-1.1.6-2.fc8.x86_64.rpm
   package-cleanup --cleandupes

that leaves me with icedax-1.1.6-2.fc8 and 'rpm -V icedax' does
not have any issues.  This is an essential progress.  Before I would
expect at least the whole documentation directory to be MIA.


Comment 8 Panu Matilainen 2007-08-20 10:23:40 UTC
Behavior on forced conflicts are one thing, this bug is about rpm removing
correctly shared files due to nasty "optimization" from old days where multilib
hardly even existed. It does affect non-multilib as well in certain
upgrade-scenarios but it's more subtle there.

The nasty hack has been axed in 4.4.2.1 and is known to fix this and various
other issues. rpm 4.4.2.1 is in updates-testing to find out any possible
regressions, verifying that this got fixed is not really needed :)

Comment 9 Fedora Update System 2007-08-27 21:46:28 UTC
rpm-4.4.2.1-1.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.


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