Bug 468161 - translation files cause multilib conflicts (again)
translation files cause multilib conflicts (again)
Product: Fedora
Classification: Fedora
Component: libgnome (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-10-23 06:36 EDT by Torsten Rausche
Modified: 2009-06-27 11:43 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-23 13:51:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Yum's failing transaction check (3.37 KB, text/plain)
2008-10-23 06:36 EDT, Torsten Rausche
no flags Details

  None (edit)
Description Torsten Rausche 2008-10-23 06:36:53 EDT
Created attachment 321264 [details]
Yum's failing transaction check

Description of problem:
The newest version of libgnome has multilib conflicts. Again the culprits are translations files (*.mo).

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

How reproducible:

Steps to Reproduce:
1. # yum install libgnome-2.24.1-5.fc10.i386 libgnome-2.24.1-5.fc10.x86_64
Actual results:
Installation/update fails because of file conflicts (see attachment)

Expected results:
No file conflicts

Additional info:
There already were attempts to fix this in previous versions
Comment 1 Matthias Clasen 2008-10-23 11:52:49 EDT
not sure what you mean with 'attempts' - the multilib conflict _was_ fixed.
Comment 2 Torsten Rausche 2008-10-23 12:57:14 EDT
(In reply to comment #1)
> not sure what you mean with 'attempts' - the multilib conflict _was_ fixed.

I just saw the bugzilla entries about the same problem in release 2.24.1-2. They told me that this problem should be fixed. Obviously it isn't fixed in the current release whereas the changelog only has an entry about a theme change after the fix...

I tried a multilib install with 2.24.1-4 now and you are right. There it WAS fixed. So let us say in release 2.24.1-5 it is broken AGAIN :)
Comment 3 Matthias Clasen 2008-10-23 13:01:57 EDT
yay, regression !
Comment 4 Bill Nottingham 2008-10-23 13:51:37 EDT
Looking at it, it's not the timestamp, it's the PO headers in the .mo file.

Should be fixed in -6, although the fix is rather gross.

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