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

Re: multiarch status update

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.

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

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.

> 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.

[1] Ok, ok.  I'm stretching it a bit, as SunOS was a different beast than
IRIX.  But if all boxes are Debian...

1KB		// Rule #6: If violence wasn't your last resort,
		// you failed to resort to enough of it.
		//   - The Seven Habits of Highly Effective Pirates

Reply to: