Handling multilib

[David Woodhouse]

On Tue, 2007-03-20 at 04:31 -0500, Jakub Jelinek wrote:
> 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. 

OK. As long as we change the default to use the _primary_ architecture
(i.e. ppc32 on ppc64) and allow the package to override that in special
cases (gdb), it could also make sense to just continue to use what RPM
already has.

Actually, I'm not sure gdb _would_ need to override the %FILECOLORS
behaviour, if it's marked as something that should be installed for the
64-bit architecture only. Perhaps we just need a system-wide default,
and the other per-package tagging I've already proposed is sufficient to
cover the rest of what we need?

-- 
dwmw2