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

[David Woodhouse]

On Wed, 2007-04-25 at 10:03 -0400, Jakub Jelinek wrote:
> On Wed, Apr 25, 2007 at 02:46:12PM +0100, David Woodhouse wrote:
> > 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.
> 
> /sbin/ldconfig doesn't care, 32-bit ldconfig on ppc can handle 64-bit
> libraries and vice versa, even on i?86 32-bit ldconfig it can handle x86_64 and
> ia64.

Ah, OK. So preferring 32-bit binaries on ppc64 and sparc64 does seem
like the right thing to do. I can't think of any case where it's wrong
(cases where you actually want _both_ packages installed, at least).

It'd certainly bring the ppc64 and x86_64 multilib closer together,
because then RPM would be choosing the the primary architecture by
default on both of them, instead of choosing the secondary arch.

> > 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.
> 
> But RPM packages can contain hints for yum and other utilities on top of
> rpm.  IMHO that's better than keeping the info in some on the side metadata.

Well, I suppose we don't _need_ that hint in RPM about specific files.
The only example I could think of was ldconfig and I was wrong about it.

So perhaps we could get away with keeping the dirty hack in RPM to
choose files, fixing the default on ppc64 and sparc64 to be 32-bit, and
just making sure we split those packages where the user might _choose_
to have a 64-bit version instead of a 32-bit version for some reason.

I don't like that much -- I'd rather get rid of the hack in RPM and get
rid of all the conflicts. But it's technically feasible, I suppose.

-- 
dwmw2