Red Hat Bugzilla – Bug 431984
Last modified: 2008-02-12 10:54:13 EST
Description of problem:
Library libraw1394 is currently few week not upgradable on my machine.
Transaction Check Error:
file /usr/lib64/libraw1394.so.8.2.0 from install of
libraw1394-1.3.0-4.fc9.x86_64 conflicts with file from package
Fan part is - my system now has two libraw1394 packages and one cannot live
without the other...
# rpm -qa libraw*
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Hmm how should I upgrade in this situation ?
These are not Fedora packages:
Pretty sure they're from ATrpms. (rpm -qi libraw1394 to verify that). You'll
either have to manually remove them and then install the other package you want,
or take the issue up with ATrpms.
Yes you are right they are from ATrpm - so who has 'hijacked' this package ?
I just believe the upgrade should be able to handle this situation.
Well, in this case, Axel packages up the old firewire stack from kernel modules
to userspace. The libraw1394 bits are rpm-newer than the f8 native bits, so at
some point, I presume you did an upgrade that pulled those bits in. Axel splits
out actual shared object files into their on sub-package, which is required by
the main package, so going from the f8 native bits (1 package) to his version (2
packages) works ok via yum. Dunno exactly why it fails trying to go the other
direction, but Axel has brought it up before. Both apt and smart handle the 2->1
transition just fine. So one could argue the bug is in yum, but I believe its
been filed and closed WONTFIX. I could be mis-remembering history though, so you
might want to bring it up with Axel and/or the yum crew.
Personally, I've already fixed this with --force flag - but if it's fine for the
maintainer to not handle this case and leave it to the users... I'll not
complain - I just think it's much better to properly handle this situation in
the .spec file...
There's no sane way to handle this situation via a spec file without pulling in
a bunch of macro voodoo that Axel uses for auto-creating his split libfoo_sover
packages to add virtual Provides:, iirc. And I have no intention of doing that.
Fixing brokenness due to choices 3rd-parties make isn't our responsibility.