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

[Ralf Corsepius]

On Thu, 2007-04-26 at 09:56 +0100, David Woodhouse wrote:
> On Thu, 2007-04-26 at 10:24 +0200, Axel Thimm wrote:
> > On Wed, Apr 25, 2007 at 10:03:00PM +0100, David Woodhouse wrote:
> > > > > > [... Changing all specfiles by splitting out bin subpackages
> > > > > > vs simply defining a new _bindir ...]

> > > RPM shouldn't be making those decisions.
> > 
> > Indeed.
> >
> > > It should just be installing what it's told to, and it shouldn't be
> > > told to install stuff which conflicts.
> > 
> > Agreed. But in your proposal of splitting out all bin parts, the bin
> > parts would still conflict, so no /usr/bin/firefox and no
> > /usr/bin64/firefox.
> 
> That's true (well, actually not for firefox right now but we plan to fix
> that and eliminate the shell script in /usr/bin). But that's because
> we've never really had 'coinstall _binaries_ of both architectures' as a
> goal of our multilib support. It's multilib, not multibin. 
> 
> Multilib is about coinstalling libraries for both runtime and
> development purposes -- but not binaries.
Exactly.

Multilibs are about 

* opening developers (note the "libs" in the name) opportunities to
build for different architectures. An aspect that has widely been
ignored by RH/Fedora, so far.

E.g. to build x86_64 binaries on "i386" (Note: This is not reversed!),
an aspect that has widely been ignored by RH/Fedora, so far.

* To allow distributors/vendors to ship binaries of
"run-time-compatible" architectures for architectures not being
supported on particular architectures.

The traditional approach (Sparc Solaris had multilibs ca a decade ago)
to this had been to not to mix architectures, like Fedora/RH currently
do, but to ship a nominal set of applications from mixed architectures,
and to install their run-time dependencies (libraries) in parallel.

>  That's a new requirement, and
> not something we've ever tried before. 
Except for testing purposes, I don't see much sense in this. Ordinary
user want "firefox" and don't care about its architecture.

But even for those (IMO, very rare occasions. firefox could be one of
these), packagers could always resort to renaming the binaries (libs
should not be affected because they already must not conflict in a
multi-arched run-time environment).

> I don't think we can manage it within the scope of the LSB. However, we
> _can_ let the user choose which binary is installed in /usr/bin. And
> perhaps we can let them install the other one with --relocate?
> 
> Do we really want to let them install both?
No, not wrt. %{_bindir} and /sbin.

Ralf