gnome-libs - 1:1.4.2-3.fc6.x86_64 Conflicts: 4 File conflict in: /etc/mime-magic.dat 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* glib-1.2.10-26.fc7.i386.rpm glib-1.2.10-26.fc7.x86_64.rpm glib-devel-1.2.10-26.fc7.i386.rpm glib-devel-1.2.10-26.fc7.x86_64.rpm gnome-libs-1.4.2-3.fc6.i386.rpm gnome-libs-1.4.2-3.fc6.x86_64.rpm gnome-libs-devel-1.4.2-3.fc6.i386.rpm gnome-libs-devel-1.4.2-3.fc6.x86_64.rpm gtk+-1.2.10-57.fc7.i386.rpm gtk+-1.2.10-57.fc7.x86_64.rpm gtk+-devel-1.2.10-57.fc7.i386.rpm gtk+-devel-1.2.10-57.fc7.x86_64.rpm imlib-1.9.13-31.fc7.i386.rpm imlib-1.9.13-31.fc7.x86_64.rpm imlib-devel-1.9.13-31.fc7.i386.rpm imlib-devel-1.9.13-31.fc7.x86_64.rpm libpng10-1.0.21-1.fc7.i386.rpm libpng10-1.0.21-1.fc7.x86_64.rpm libpng10-devel-1.0.21-1.fc7.i386.rpm libpng10-devel-1.0.21-1.fc7.x86_64.rpm ORBit-0.5.17-20.fc7.i386.rpm ORBit-0.5.17-20.fc7.x86_64.rpm ORBit-devel-0.5.17-20.fc7.i386.rpm ORBit-devel-0.5.17-20.fc7.x86_64.rpm # 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).
Confirmed.
*** Bug 175750 has been marked as a duplicate of this bug. ***