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 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.
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)
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?
*** Bug 248884 has been marked as a duplicate of this bug. ***
*** Bug 251345 has been marked as a duplicate of this bug. ***
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.
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.
> 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.
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 :)
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.