From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-1.3.1 Firefox/1.0.3 Description of problem: i386 version of perl is missing from x86_64 updates repository causing updates to fail with conflicts: [root@weasel ~]# yum update ... Finished Transaction Test Transaction Check Error: file /usr/share/man/man1/c2ph.1.gz from install of perl-5.8.5-11.FC3 conflicts with file from package perl-5.8.5-9 file /usr/share/man/man1/cpan.1.gz from install of perl-5.8.5-11.FC3 conflicts with file from package perl-5.8.5-9 file /usr/share/man/man1/dprofpp.1.gz from install of perl-5.8.5-11.FC3 conflicts with file from package perl-5.8.5-9 file /usr/share/man/man1/enc2xs.1.gz from install of perl-5.8.5-11.FC3 conflicts with file from package perl-5.8.5-9 file /usr/share/man/man1/find2perl.1.gz from install of perl-5.8.5-11.FC3 conflicts with file from package perl-5.8.5-9 file /usr/share/man/man1/h2ph.1.gz from install of perl-5.8.5-11.FC3 conflicts with file from package perl-5.8.5-9 file /usr/share/man/man1/h2xs.1.gz from install of perl-5.8.5-11.FC3 conflicts with file from package perl-5.8.5-9 file /usr/share/man/man1/libnetcfg.1.gz from install of perl-5.8.5-11.FC3 conflicts with file from package perl-5.8.5-9 ... Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Try to apply updates to FC3 x86_64 system which has perl installed Actual Results: See description... Additional info: Easily fixed by copying the i386-version of this update to x86_64 repository as well. Or worked around by just removing the i386-version of perl, I kinda wonder why is it included in the first place since nothing seems to need it?
perl is not a multilib package. It was originally pushed there erroneously. Please remove the i386 version before upgrading.
(This means x86_64 users should use 'yum remove perl.i386'. We have no other way out of this unfortunately.)
*** Bug 156379 has been marked as a duplicate of this bug. ***
*** Bug 156444 has been marked as a duplicate of this bug. ***
*** Bug 156473 has been marked as a duplicate of this bug. ***
*** Bug 156565 has been marked as a duplicate of this bug. ***
Warren: "We have no other way out of this..." Why not reissue perl.x86_64 as 5.8.5-12 and mark it as obsoleting the earlier i386 version? If there is some reason that this is infeasible, this needs a notice somewhere so that people can figure out what's up.
And while I'm thinking about it. This should not be "closed notabug". It bloody well is a bug. It should be marked as "closed wontfix" or "closed deferred". Don't corrupt the bug database with bad data!
It is impossible to Require/Obsolete/Conflict a different arch.
Does anyone know what the effect of this will be if you try to upgrade a FC3 box to FC4? Will it cause the upgrade to fail? If so, should there be a nasty hack in anaconda which removes perl.i386? Or would an item in the release notes be enough?
I tested that today. The results are disasterous. I'm trying to get a nasty hack added to anaconda because you cannot rely on humans to read documentation.
If I understand Warren's comment, it is not possible today for an RPM on one architecture to obsolete an RPM from another architecture. In principle, I don't see any reason why an Obsoletes: line should not be able to specify obsoletes behavior across architectures. Given that several targets are now multiarchitecture at user level (notably x86_64, ia64), should this be filed as a recommended enhancement for RPM?
*** Bug 157169 has been marked as a duplicate of this bug. ***
You also might want to investigate why Bugzilla searches on either perl-5.8.5-11.FC3 or perl-5.8.5-9 both find nothing, even when searching descriptions. That is why you are getting so many duplicates. It's quite annoying to do multiple searches before going to the trouble of writing up a bug, only to find it's a dupe anyway.
*** Bug 157337 has been marked as a duplicate of this bug. ***
*** Bug 159893 has been marked as a duplicate of this bug. ***