Bug 219935 - files from i386 package conflict with x86_64 during update
files from i386 package conflict with x86_64 during update
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
6
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-16 23:12 EST by Chris Petersen
Modified: 2014-01-21 17:56 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-19 13:50:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Petersen 2006-12-16 23:12:18 EST
Please see bug #189958 as well, which I'm guessing has been misfiled under
libgnome instead of yum.

Basically, if a user has both 32 and 64 bit versions of a package installed, yum
will occasionally give what turns out to be a cryptic error message. e.g.

Transaction Check Error:   file /usr/share/easytag/ChangeLog from install of
easytag-1.99.13-1.fc6 conflicts with file from package easytag-1.99.12-3.fc6
  file /usr/share/man/man1/easytag.1.gz from install of easytag-1.99.13-1.fc6
conflicts with file from package easytag-1.99.12-3.fc6

It's especially maddening because yum doesn't report the arch when it shows the
error, so unless the user knows what he/she is looking at, the error reported
reads like the new package is conflicting with the one it's supposed to be
replacing.

I believe this only happens when the 32 bit version of an update isn't available .
Comment 1 Jeremy Katz 2006-12-19 13:50:20 EST
This is a bug in the package; if it's intended to be multilib (and thus gets
pushed to the repo as such), then it shouldn't have file conflicts like this.
Comment 2 Chris Petersen 2006-12-19 14:02:29 EST
This means that at least half of core, updates and extras are broken.  How do
you expect things like man pages, which NEED to be installed for each arch of
the package, to be handled?

No problems happen if you upgrade both packages simultaneously, so it seems to
me that if there is a problem when you upgrade only ONE of the two, it's a bug.

Comment 3 Alex W. Jackson 2007-01-08 17:54:49 EST
No, it isn't a bug.  Having multilib packages of mismatched versions installed
(e.g. foo.1.2-3.x86_64 and foo.1.2-1.i386) isn't supported.  The installed
64-bit and 32-bit versions of a multilib package have to be the exact same
version and release, which means you always have to update them together.
Comment 4 Chris Petersen 2007-01-08 18:16:03 EST
I hadn't seen this as a version issue..  In my experience, this has been
happening when I have foo.1.2-3.x86_64, and then I install foo.1.2-3.i386 and
get the error.  But it's just as likely that I haven't been paying attention to
the release number and perhaps the 32 bit and 64 bit repositories are
occasionally slightly out of sync (which is why this error only shows up
occasionally and not on every update).

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