Bug 124019

Summary:	biarch/multilib package confliction is buggy
Product:	[Fedora] Fedora	Reporter:	Nicholas Miell <nmiell>
Component:	rpm	Assignee:	Jeff Johnson <jbj>
Status:	CLOSED NOTABUG	QA Contact:	Mike McLean <mikem>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-05-24 14:54:01 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nicholas Miell 2004-05-22 23:16:01 UTC

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.)

Comment 1 Jeff Johnson 2004-05-24 14:54:01 UTC

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 22:53:39 UTC

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 20:56:21 UTC

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-28 00:26:34 UTC

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.