Handling multilib

[Jakub Jelinek]

On Tue, Mar 20, 2007 at 09:17:33AM +0000, David Woodhouse wrote:
> 4. When we install both versions in parallel and there are conflicting
> files, what do we do? Refuse to install it? Let files for primary arch
> override secondary? Let files for 64-bit override 32-bit?
> 
>    Currently, RPM is has hardcoded exceptions so that it can install
>    packages with conflicting files. When there are different executables
>    it'll choose the 64-bit one, even on ppc64 where the 32-bit one is
>    the "primary arch" and would usually be the better choice. So we end
>    up with a mix of 32-bit and 64-bit executables in /usr/bin.
> 
>    There are those who would argue that we  should allow "conflicting"
>    files only when they're identical -- not for executables. Thus we
>    should split executables and libraries into separate packages, so
>    that the libs can be installed in both flavours while the executables
>    may only be installed in one version at a time.
> 
>    That makes sense to me -- the alternative is to just screw around a
>    little more with RPM's hardcoded behaviour, which seems wrong.

It is not that hardcoded.  Files with non-zero %FILECOLORS can be installed
from either package (and just rpm decides which one wins, here IMHO should
be a per-package and system default configurable preference),
files with zero %FILECOLORS can't conflict between different arches.
Try:
rpm -q --qf '[%{FILECOLORS} %{FILENAMES}\n]' glibc

I'm not arguing that it is sometimes desirable to split off a library
package when you want libraries to be multilib, but they occupy only very
small part of the whole package.  But forcing splitting of every second
package is IMHO an overkill and rpms %FILECOLORS can do its work there.
For packages where you have a bunch of libraries and one or two small
binaries and a few small data files lib subpackages would just clutter
the package universe.

	Jakub