[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: multiarch status update



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.

Am I arguing for bi-arch?  If so, so be it.  KISS.

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.

-- 
-----------------------------------------------------------------
Ron Johnson, Jr.
Jefferson, LA USA

The enemy thinks and plans and strategizes, too.



Reply to: