Richard L. Hamilton wrote: > Why not avoid the problem by putting all the FSF stuff in /usr/gnu, > and having an optional package of symlinks in /usr/bin which no other > package with dependencies on the /usr/gnu stuff should require? That way, > users could choose whether to have non-conflicting /usr/gnu commands added > to /usr/bin, or whether to leave them out; rather than building their > own directory of symlinks to non-GNU commands in /usr/bin and putting > that directory ahead of their directory of self-built GNU commands.
I see the incorporation of FSF components into OpenSolaris as exactly that - incorporation - being made part of the body of the OS, not some optional wart bolted onto the side. What we're trying to do is assemble a consistent, integrated set of components that work together as delivered, regardless of license. If /usr/bin contains FSF components only on some Solaris systems, we've forced anyone who uses a multiplicity of Solaris machines to cobble a path together from distinct pieces in order to very slightly simplify the work of those who wish to replace certain portions of a particular OpenSolaris build with different parts. OpenSolaris supports multiple command environments, but it does so through placing alternate versions of commands found in /usr/bin ahead in the user's path. This allows a user to specify his path, and have it work on any machine running that version of OpenSolaris. I suggest that anyone seeking to construct alternate environments continue in this vein, and create their own directory containing either alternate binaries or links to the desired system version. This allows each user to construct their own ideal working environment, while maintaining a simple, easily understood and consistent environment for those willing to accept the choices made by the OpenSolaris developers. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
