gnome-libs - 1:1.4.2-3.fc6.x86_64
File conflict in:
Packages with the same files:
gnome-libs - 1:1.4.2-3.fc6.i386
I've just done this:
# ls -1 gnome* ORB* imlib* glib* gtk* libpng10*
# yum localinstall gnome* ORB* imlib* glib* gtk* libpng10*
and that succeeded on my FC6.x86_64 system (albeit with *lots* of .rpmnew files
in /etc/gtk from the config files in the gtk+ packages). I can see that
/etc/mime-magic.dat is different in the i386 and x86_64 packages but it doesn't
seem to upset rpm/yum on FC6. Is FC7 more sensitive to this?
As for a possible fix, how about %ghost-ing /etc/mime-magic.dat and generating
it from /etc/mime-magic in %post?
Your report says "Conflicts: 4"; what are the other conflicts?
/etc files create no conflict if they are marked %config.
The interesting question is why is mime-magic.dat a binary file?
Is it arch-independent? The differences in a hex-dump look quite big.
How is it accessed? And if both i386 and x86_64 gnome-libs are installed,
can the i386 code read the x86_64 mime-magic.dat and vice versa?
I believe I have a fix for this now. The mime-magic.dat file is basically the
contents of a glib array dumped into a file. The elements of the array are not
zeroed out before they are set up, so parts not explicitly written to get
seemingly random values. Just adding a call to memset() at the top of the loop
that sets up the array results in identical files on i386 and x86_64.
Are there any other conflicts in this package or is it OK to commit this fix and
build new packages now?
No other files create a conflict.
OK, should be fixed in gnome-libs-1.4.2-4.fc7 (should be in the needsign queue).
*** Bug 175750 has been marked as a duplicate of this bug. ***