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

[Dominik 'Rathann' Mierzejewski]

On Friday, 27 April 2007 at 20:08, Axel Thimm wrote:
> On Fri, Apr 27, 2007 at 07:57:11PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> > On Friday, 27 April 2007 at 19:34, Ed Hill wrote:
> > > There are no technical reasons why it can't be done so why try to
> > > impose some artificial (and IMO self-defeating) barriers?
> > 
> > Because that's what we've been doing for years?
> 
> But honestly, that really isn't a reason for not fixing something?

I'm all for fixing, but not by changing known behaviour all of a sudden
instead of fixing what's broken.

> > If you want to start talking about multiarching, we can do that,
> > too, but the topic at hand is different.
> 
> One way to solve all multilib problems is to scratch multilib

I agree. I use pure arch anyway.

> and use multiarch, e.g. avoid the arch-overwriting mechanism we currently
> use, so I wouldn't say we're off-topic in considering multi-arch.

Well not in near future anyway (read: F7). Perhaps for F8/F9.

> > Yes, there's no technical reason for not installing both 32bit and 64bit
> > version at the same time, but it means we'd need to go down the bin{32,64}
> > path and that's a major change which I'm firmly against.
> 
> OK, but why? Any suggestions need to be considered based on benefits
> and drawbacks. If at the end there are more benefits that drawback one
> chooses that, but w/o analysing it and blocking something from the
> start you may miss important opportunities.

I think multiarch is pointless (chroot solves that without rebuilding
everything). Having said that, let's consider it.

We have the following options:

1a)
on x86_64:
primary arch is 64bit and /bin /lib etc contain 64bit binaries.
secondary arch is 32bit and /bin32 /lib32 etc contain 32bit binaries.

1b)
on x86_64:
primary arch is 64bit and /bin64 /lib64 etc contain 64bit binaries.
secondary arch is 32bit and /bin /lib etc contain 32bit binaries.

2)
on ppc64/sparc64:
primary arch is 32bit and /bin /lib etc contain 32bit binaries
secondary arch is 64bit and /bin64 /lib64 etc contain 64bit binaries.

2) is straightforward, requires putting bin64 after bin in $PATH. 1a is
IMHO "natural", but requires different 32bit repo for x86_64. 1b requires
putting bin64 first in $PATH. That probably leaves us with 1b and 2.

So while I may not like it, I see no technical reason against this
solution. Nevertheless I still don't like it!

In an ideal world, we'd have just /bin and /lib (etc.) containing
native binaries.

Regards,
R.

-- 
Fedora Extras contributor  http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"