Re: multiarch status update
Adam Borowski <kilobyte@angband.pl> writes:
> On Thu, May 11, 2006 at 04:49:26PM -0400, Joe Smith wrote:
>> On the other hand, if we continue that thought process we could end up
>> with all headers and libraries in /usr/share/, which is absurd.
>
> Why? This is exactly what's beautiful, especially if EVERYTHING ends up in
> /usr/share/ at one day, at which point /share/ will be redundant and the FHS
> will change.
>
>> Indeed, the current proposal almost seems to be reversing this.
>> >Non-target specific libraries and header files remain in $prefix/lib and
>> >$prefix/include.
>> It seems to me that libraries and headers that are not target specific are
>> supposed to go in /usr/share.
>> That is because if they are not target specific they are most certainly
>> cross-platform.
Maybe they should. The amount of software thatr assumes /usr/include
is being used might be to big of a problem though to get that changed
any time soon.
> I remember a lab that consisted mostly of SGI Indy boxes, a SunOS server,
> some O2 and a stray Linux or two. The common problem was incompatibility of
> binaries: things compiled on an Indy worked on the Indies and O2, but things
> compiled on O2 were incompatible with Indy. Exactly the same thing as
> i386->i486->i586->i686->amd64.
>
> Now, imagine that /usr/bin is split this way:
> /usr/bin (perl, bash)
> /usr/bin/indy (binaries)
> /usr/bin/o2 (binaries)
> /usr/bin/sun (binaries) [1]
> Can you see what I mean? By just having different PATHs, everything would
> be completely transparent. And the multiarch would take care of all
> libraries and headers.
That would be total insanity. Just think about the number of scripts
with "#!/usr/bin/python" in it that would have to be changed. And how
would you even change them to pick the right architectures python?
Same for sh, perl, javal, ocaml, .....
Also depending on PATH to be specific for each arch would be a
violation of debian policy somewhere.
>> Hm... This entire concept seems messy. It seems that processors that
>> support multiple architectures, as well as cross compilition are begining
>> to blur the line between /usr and /usr/share.
>
> It's not "messy", it's plain awesome. And if the line gets blurred into
> oblivion, it will be a reason for joy.
No solution for multiarch I've seen so far has changed anything for
cross compiling though. That is quite a different story.
MfG
Goswin
Reply to: