Bug 219935

Summary: files from i386 package conflict with x86_64 during update
Product: [Fedora] Fedora Reporter: Chris Petersen <lists>
Component: yumAssignee: Jeremy Katz <katzj>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6   
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-12-19 18:50:20 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 Chris Petersen 2006-12-17 04:12:18 UTC
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 18:50:20 UTC
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 19:02:29 UTC
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 22:54:49 UTC
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 23:16:03 UTC
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).