[F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl)

[David Woodhouse]

On Wed, 2007-04-25 at 07:16 -0400, Jakub Jelinek wrote:
> I believe there is no reason to kill rpm's multilib handling, as long as
> it is configurable which arch is preferred (so that we don't prefer
> say ppc64 on ppc where 32-bit code is generally faster) and as long as
> there is some way for packages to override this (a "prefer {32,64}-bit
> flag"). 

I've hacked up something like this as a test -- I've made RPM's
preference of 32-bit vs 64-bit be configurable.
http://david.woodhou.se/rpm-4.4.2-prefer-elf32.patch

I'm doing an install with anaconda modified to set %_prefer_color to 1
on ppc64, so that we prefer 32-bit. I expect it to work fine except
for /sbin/ldconfig, which is about the only case where we _do_ want
64-bit.

(I don't include gdb in the above statement because there's no need for
the 32-bit gdb to be installed and to force RPM to choose; while there
_is_ a need for both versions of glibc, which is what provides 
/sbin/ldconfig.)

Of course, if /sbin/ldconfig wasn't in the same package as the libc
libraries, and we could install _just_ the 64-bit version of the package
which contains ldconfig, it would be fine.

We could perhaps contrive ways to indicate to RPM that we want a certain
flavour of binary to be preferred when both are installed simultanously
-- but I can't see any way to do it which isn't going to be ugly, and
really it's none of RPM's business -- it's the job of yum or the user,
or whatever/whoever _calls_ RPM to make decisions about what should be
installed.

I think it's much better to have a packaging policy which forbids the
file conflicts -- letting RPM deal with them by second-guessing was only
ever a dirty hack.

> If we through some tag annotate all packages ("this package should be
> only installed for the primary arch", "this package can be installed for
> both arches if needed (usually library package)", "this package should
> only be installed for one arch, preferrably XYZ"), then yum etc. can
> make smart decisions fairly cheaply and we can also use the separate
> arch repositories easily. 

That makes some sense, but it's for _yum_, as you say. Not for RPM
(where it might have to be per-file anyway).

-- 
dwmw2