Bug 247749

Summary: rpm -e for multiple architecture packages removes common files
Product: [Fedora] Fedora Reporter: Piergiorgio Sartor <piergiorgio.sartor>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 7CC: gustavo, michal, michel.salim, robert3
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 4.4.2.1-1.fc7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-08-27 21:47:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.