Local conflict between packages (586 and x86_64)

[bwjpg]

Have had FC 11 64bit installed and for about two months now.

Updates through the automatic software update facility worked fine

Until...

Last week when I got an update for the GIMP toolkit (GTK+ - a bug fix) and XOrg X11 (enhancement)

Here's the error messages

For GTK

Test Transaction Errors: file /usr/share/locale/af/LC_MESSAGES/gtk20.mo from install of gtk2-2.16.5-1.fc11.x86_64 conflicts with file from package gtk2-2.16.2-1.fc11.i586
file /usr/share/locale/am/LC_MESSAGES/gtk20.mo from install of gtk2-2.16.5-1.fc11.x86_64 conflicts with file from package gtk2-2.16.2-1.fc11.i586
file /usr/share/locale/ang/LC_MESSAGES/gtk20.mo from install of gtk2-2.16.5-1.fc11.x86_64 conflicts with file from package gtk2-2.16.2-1.fc11.i586
file /usr/share/locale/ar/LC_MESSAGES/gtk20.mo from install of gtk2-2.16.5-1.fc11.x86_64 conflicts with file from package gtk2-2.16.2-1.fc11.i586
file /usr/share/locale/as/LC_MESSAGES/gtk20.mo from install of gtk2-2.16.5-1.fc11.x86_64 conflicts with file from package gtk2-2.16.2-1.fc11.i586
file /usr/share/locale/ast/LC_MESSAGES/gtk20.mo from install of gtk2-2.16.5-1.fc11.x86_64 conflicts with file from package gtk2-2.16.2-1.fc11.i586
file /usr/share/locale/az/LC_MESSAGES/gtk20.mo from install of gtk2-2.16.5-1.fc11.x86_64 conflicts with fil...

For XOrg

Test Transaction Errors: file /usr/share/X11/locale/el_GR.UTF-8/Compose from install of libX11-1.2.2-1.fc11.x86_64 conflicts with file from package libX11-1.2.1-2.fc11.i586
file /usr/share/X11/locale/en_US.UTF-8/Compose from install of libX11-1.2.2-1.fc11.x86_64 conflicts with file from package libX11-1.2.1-2.fc11.i586
file /usr/share/X11/locale/fi_FI.UTF-8/Compose from install of libX11-1.2.2-1.fc11.x86_64 conflicts with file from package libX11-1.2.1-2.fc11.i586
file /usr/share/X11/locale/iso8859-1/Compose from install of libX11-1.2.2-1.fc11.x86_64 conflicts with file from package libX11-1.2.1-2.fc11.i586
file /usr/share/X11/locale/iso8859-15/Compose from install of libX11-1.2.2-1.fc11.x86_64 conflicts with file from package libX11-1.2.1-2.fc11.i586
file /usr/share/X11/locale/iso8859-9/Compose from install of libX11-1.2.2-1.fc11.x86_64 conflicts with file from package libX11-1.2.1-2.fc11.i586
file /usr/share/X11/locale/iso8859-9e/Compose from install of libX11-1.2.2-1.fc11.x86_64 conflicts wit...

As you can see the x86_64 version conflicts with an i586 version.

I didn't know I even had an i586 version of anything.

I just have a plain vanilla install.

The only odd thing is that I recently installed Wine.

From my own research I could attempt to use yum but given the vital role of XOrg I don't feel like doing anything risky until I've had a second opinion.

[ccjon]

I am having the same conflicts, (and haven't installed wine) ...

Not sure how to switch to 64 bit versions of gtk2 without removing about 40 dependencies as well.

[Hlingler]

The only odd thing is that I recently installed Wine.

WINE is 32-bit only - all dependencies required would be required to be 32-bit. Note that 32-bit software packages are perfectly "legal" on a 64-bit Fedora OS ("multi-lib" feature) in most cases, but with a few notable exceptions.

The conflicts that you have listed are non-critical: they are all locale files (various language translations of stuff). It also appears that the 32-bit updates conflict with already-installed 64-bit packages. You can:
> Exclude the offending 32-bit packages from updates until the issue is resolved
> Force the updates with RPM manually
> Try enabling updates-testing repo to relieve the bottleneck; this may open you to additional issues.

V

[wangmaster]

i've had the same types of conflicts all the time through the GUI packagekit apps. Whenever I use yum update, the same update succeeds. I've not had to force rpms manually or anything. So I've just settled on using yum to do all my update work.

[Dan]

Same conflicts here ... waited 24 hours, re-tried updates ... everything popped right in.

[bwjpg]

Just did a big batch of updates (including a kernel update) and problem seems to have solved itself.