Red Hat Bugzilla – Bug 124019
biarch/multilib package confliction is buggy
Last modified: 2007-11-30 17:10:43 EST
For some reason, rpm happily installs gtk2.i386 and gtk2.x86_64,
despite the fact that they conflict (both put different binaries in
Which binaries you get is apparently random. (I think the last
installed package wins.)
I noticed this when I was trying to figure out why a newly installed
gtk input method wasn't working. It turns out that the the 32bit
version of /usr/bin/gtk-query-immodules-2.0 was installed, and it was
generating /etc/gtk-2.0/gtk.immodules based on 32bit libraries.
So, I think the desired rule for multilib package confliction should be:
Two versions of the same package conflict iff any overlapping files
This would allow the different libs to get installed in /usr/lib and
/usr/lib64, while still sharing common data and documentation files
and preventing the clobbering of binaries. (Binaries would get split
off into a seperate package, like what happened with freetype-utils.)
Nope, the desired rule is
Executables should behave the same independent of elf32/elf64.
If there is a significant difference in behavior between the
i386 and x86_64 executables, then this bug needs to be reopened
and assigned to gtk2, not rpm.
Explain to me how an elf32 executable is supposed to dlopen() an elf64
library, call some functions that return info about the library, and
then write a config file based on that data.
An elf32 is supposed to read its own elf32 modules, same
for elf64. If that isn't happening for some executable, then
there's a bug with that executable, not rpm.
Again, reopen and assign the bug against gtk2 if you wish.
rpm ain't the place to argue the issue.
So, I recently removed libjpeg.i386.
Because it was installed after libjpeg.x86_64, the 32bit versions of
libjpeg tools were installed to /usr/bin, overwriting the 64bit versions.
On removal of libjpeg.i386, rpm left behind the 32bit versions of the
tools (becase the 64bit version of the package also provided binaries
at that location), but happily deleted the 32bit library that they
Thus, broken jpeg tools.
If non-identical overlapping files caused conflicts, this wouldn't be