This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 431984 - Upgrade problem
Upgrade problem
Product: Fedora
Classification: Fedora
Component: libraw1394 (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Jarod Wilson
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-02-08 03:57 EST by Zdenek Kabelac
Modified: 2008-02-12 10:54 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-08 12:28:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Zdenek Kabelac 2008-02-08 03:57:52 EST
Description of problem:

Library libraw1394 is currently few week not upgradable on my machine.
Transaction Check Error:
  file /usr/lib64/ 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*
65026 libraw1394-1.3.0-3_11.fc8.x86_64
23248 libraw1394_8-1.3.0-3_11.fc8.x86_64

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:
Hmm how should I upgrade in this situation ?

Additional info:
Comment 1 Jarod Wilson 2008-02-08 12:28:26 EST
These are not Fedora packages:

65026 libraw1394-1.3.0-3_11.fc8.x86_64
23248 libraw1394_8-1.3.0-3_11.fc8.x86_64

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.
Comment 2 Zdenek Kabelac 2008-02-11 05:22:21 EST
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.
Comment 3 Jarod Wilson 2008-02-11 14:13:07 EST
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.
Comment 4 Zdenek Kabelac 2008-02-12 10:25:51 EST
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...
Comment 5 Jarod Wilson 2008-02-12 10:54:13 EST
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.

Note You need to log in before you can comment on or make changes to this bug.