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

[Axel Thimm]

On Sun, Apr 29, 2007 at 08:43:59PM +0200, Christian Iseli wrote:
> On Sat, 28 Apr 2007 13:17:26 +0200, Axel Thimm wrote:
> > There could also be
> > 
> > 3) No one gets /bin, /lib directly, everything gets bult into
> >    bin32/bin64 etc. and bin and lib are set as follows (symlinks)
> > 
> >    i386: bin -> bin32, lib -> lib32
> >    x86_64: bin -> bin64, lib -> lib64
> >    ppc: bin -> bin32, lib -> lib32
> >    ...
> > 
> >    That would give you proper symmetry, reusable packages from one
> >    arch onto another (e.g. not packaging extra i386 packages for
> >    x86_64), and bin/lib would always point to the native components.
> 
> Another type of thing that worries me with this schema:
> $ rpm -qf /bin/ls
> file /bin/ls is not owned by any package
> 
> In short: you are throwing a whole lot of typical assumptions
> about a Unix/Linux system out the window... and my gut feeling is that
> they'll come back haunting us in various unpleasant ways for a long
> time.

That's a problem in general that we need to be aware of. The moment
any scheme starts not to prepare multilib/multiarch on the server
side, but simply activate both repos on the client side you will have
the issue that /bin/ls will be owned by two packages from different
archs, and you need to hope that the depsolver will pick the right
one.

But this is a common issue with any scheme that will allow full
unfiltered access to both repos.

In the scheme 3) above one could automatically %ghost-own all (s)bin
symlinks, which would solve the issue of /bin/ls existing in the rpm
database, but not the general issue of parallel repo enablement.

So, in a nutshell: There will be two classes of solutions, one that
prepare the x86_64 repo with selected i386 packages, either
white/blacklisted/heuristic based etc, or solutions that allow full
access to the i386 repos. And the latter class of solution will have
to deal with shared file dependencies. Both the bin64 and David's
solution fall into the latter class.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070430/a209aecb/attachment.sig>