Re: multiarch status update
Ron Johnson <ron.l.johnson@cox.net> writes:
> On Wed, 2006-05-17 at 00:01 +0200, Goswin von Brederlow wrote:
>> "Olaf van der Spek" <olafvdspek@gmail.com> writes:
>>
>> > On 5/15/06, Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:
>> >> Bill Allombert <ballombe@master.debian.org> writes:
>> >>
>> >> > On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote:
>> >> >> I so far haven't seen any compelling arguments for multiarchifying the
>> >> >> whole archive including all of */bin.
>> >> >
>> >> > Personnally I would favor a new files hierachy that allow every
>> >> > arch-dependend files to be co-installable. Even if we are not able to
>> >> > take full advantage of it at once, it seems saner and more forward-looking
>> >> > than only allowing libraries to be co-installable. This might also make
>> >> > easier to have this new scheme adopted by other OS.
>> >> >
>> >> > Cheers,
>> >>
>> >> But would make it totaly incompatible with existing systems.
>> >
>> > Why do you think there's no compatible solution?
>>
>> Because basicaly all sources assume binaries go to <prefix>/bin. You
>> want to break that. Also a lot of scripts expect binaries to be where
>> they are and anything setting PATH too.
>>
>> We have thought hard about this over the last 2 years and nobody has
>> come up with a non disruptive way
>
> Is "non-disruptive" that vital? What about "minimally disruptive",
> or "a little disruptive"?
>
> As a user, I'd put up with some one-time disruption if that means
> that I could have 64-bit coolness (after all, I'm a home user) while
> keeping 32-bit goodness like OOo2 & w32codecs.
But why would you want to put up with it at all? Do you realy need
both a 32bit OOo and a 64bit OOo? Or both 64bit and 32bit video
players? Isn't one of the two enough?
By only alowing one arch per binary we have a totaly non disruptive
way of implementing multiarch that is fully upwards and downwards
compatible with etch (and only needs a ld.so.conf entry in
sarge). Allowing multiple archs for one binary just solves a problem
that we don't have and adds a ton of complexity not to mention changes
to packages. We are talking 100 vs. 16000.
MfG
Goswin
Reply to: