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