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

[Axel Thimm]

On Fri, Apr 27, 2007 at 08:36:53PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> 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.

It's not all of a sudden, it is something suggested for being reviewed
for F8.

> > > 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.

Check the subject line, it was never ever intended for F7. :)

> > > 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.

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.

I think there are lots of variants, even using different folder
names. The main aspect that separates this from multilib is that it
has different folders for binaries of the different archs.

And FWIW if that other folder is in a chroot, that would be fine with
me as well (maybe not called multiarch anymore, but names are just
sound and smoke) - the important thing is no more filecolor induced
file overwrites or remove/install punchholes, and also not replacing
this by file-conflicting bins that need to be redownloaded each time
for switching.
-- 
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/20070428/d3cafff8/attachment.sig>