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

[Jakub Jelinek]

On Wed, Apr 25, 2007 at 10:52:40AM +0200, Axel Thimm wrote:
> The default setup is to use x86_64 bits. Pruning the (s)bin64 parts
> out of the path you get a pure i386 system (with annoying lib64
> folders, see below).

{,s}bin64 is a terribly bad idea.  For almost all binaries (very few
exceptions) users don't really care whether they are running 64-bit
or 32-bit binary, it should have exactly the same functionality.
So having both /bin/ls and /bin64/ls serves no useful purpose (in addition
to violating FHS).  The exceptions are:
1) programs where the 64-bit version can handle 32-bit and 64-bit stuff,
but the 32-bit one can't (on i386/x86_64 this is e.g. gcc (but on say
ppc/ppc64 not), gdb, strace, and a few others) - this is best solved
by just telling the package management about it - some "prefer 64-bit flag"
2) programs that use plugins which aren't for whatever reason available
for both wordsizes - firefox, perhaps perl, python.
For firefox this is easily solvable, as /usr/bin/firefox is just a shell
wrapper script, it wouldn't be hard to add --prefer32 and --prefer64
options to it to tweak the hardcoded preference.  For python/perl
it can very well be handled by also shipping the binary in
/usr/lib{,64}/{python,perl}*/{python,perl} or something, you don't need
to create bin64 dirs for this

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").  For an average library package which contains a bunch of big
libraries and a couple of small binaries and/or data files in addition
to that rpm's multilib can be used just fine.  But there should be a policy
that when the binaries and/or data files occupy a big part of the package
the libraries should be split into a subpackage, to e.g. limit the download
sizes.
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.

	Jakub