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: >> >> >> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]