For some reason, rpm happily installs gtk2.i386 and gtk2.x86_64, despite the fact that they conflict (both put different binaries in /usr/bin). 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 are non-identical. 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 require. Thus, broken jpeg tools. If non-identical overlapping files caused conflicts, this wouldn't be a problem.