On Wed, 2006-05-17 at 10:34 +0200, Goswin von Brederlow wrote:
> Ron Johnson <[EMAIL PROTECTED]> writes:
>
> > On Wed, 2006-05-17 at 00:01 +0200, Goswin von Brederlow wrote:
> >> "Olaf van der Spek" <[EMAIL PROTECTED]> writes:
> >>
> >> > On 5/15/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> >> >> Bill Allombert <[EMAIL PROTECTED]> 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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
