Red Hat Bugzilla – Bug 247749
rpm -e for multiple architecture packages removes common files
Last modified: 2007-11-30 17:12:10 EST
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
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):
Always, if there are common files
Steps to Reproduce:
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
Remove one package for one architecture:
rpm -e pckg-1.2-3.fc7.i386
Check the remaining one:
rpm -qV pckg
Often, some missing files are reported.
The verification (as above) should return more or less no problems.
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
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 22.214.171.124 is planned for F7 as an update)
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
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?
*** Bug 248884 has been marked as a duplicate of this bug. ***
*** Bug 251345 has been marked as a duplicate of this bug. ***
rpm-126.96.36.199-1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
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.
> 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-188.8.131.52-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
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.
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 184.108.40.206 and is known to fix this and various
other issues. rpm 220.127.116.11 is in updates-testing to find out any possible
regressions, verifying that this got fixed is not really needed :)
rpm-18.104.22.168-1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.