Re: multiarch status update
Ron Johnson <ron.l.johnson@cox.net> writes:
> On Wed, 2006-05-17 at 10:34 +0200, Goswin von Brederlow wrote:
>> 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:
> [snip]
>> >>
>> >> 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?
>
> No.
>
> $JOE_USER will, ISTM, only need to (want to)run a few 32-bit apps
> on his otherwise 64-bit system.
>
> OOo2 (until it becomes 64-bit clean)
> w32codecs (and thus every app that depends on it)
> Wine
> other OSS apps that aren't 64-bit clean
> binary apps:
> Adobe Acrobat Reader
> Macromedia Flash player
> Crossover Office
> Sun Java ?
>
> And this implies apps like Firefox, since many of these apps have
> plugins for FF & Mozilla, and the libraries they depend on. (Yes,
> closed source is impure, blah, blah, worship RMS, but the sad fact
> is that they are *useful*.)
>
>> 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.
>
> It looks like we agree on this. The scope should be narrow and
> "downhill", i.e., ia32 apps on x86_64, PPC32 apps on PPC64, SPARC32
> on SPARC64 systems. No uphill, and no complications like all the
> different MIPS permutations running together.
No. Only on ia64 and amd64 do you want to default to 64bit. Ia64
because 32bit mode is emulated and amd64 because the ton of extra
regioster make it faster in general. All other archs suffer from the
extra memory and bandwith required for the larger pointer and are
considerably slower in 64bit mode.
But it doesn't realy matter what you call up or downhill. One arch
gets set as prefered or each one gets a pin and the best one available
wins unless overrules by the user.
> Am I arguing for bi-arch? If so, so be it. KISS.
You are arguing not to have the same binary for multiple architecture
installed but different binaries from different architectures. Bi-arch
or multiarch is just implementation detail for you. It is what most
sane people want.
> Still, in a universe as large as Debian, some group of users must
> have a reason to need to/want to be able to install side-by-side
> architectures of the same packages.
>
> However, there's no need to make this totally transparent.
>
> People who want to run 32-bit apps in a 64-bit world would have
> to EXPLICITLY run a script that changes that process' personality
> (using linux32) and then runs /usr/bin/${SOMEAPP}_32.
Nah, linux32 just changes the output of uname. Nearly everything has
no need to query that information and you just start it. Alternatives
are much simpler and more transparent for the user.
MfG
Goswin
Reply to: