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"
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
