Bug 124019 - biarch/multilib package confliction is buggy
biarch/multilib package confliction is buggy
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2004-05-22 19:16 EDT by Nicholas Miell
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-05-24 10:54:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nicholas Miell 2004-05-22 19:16:01 EDT
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
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.)
Comment 1 Jeff Johnson 2004-05-24 10:54:01 EDT
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.
Comment 2 Nicholas Miell 2004-05-24 18:53:39 EDT
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.
Comment 3 Jeff Johnson 2004-05-26 16:56:21 EDT
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.
Comment 4 Nicholas Miell 2004-05-27 20:26:34 EDT
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
a problem.

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