Bart Smaalders wrote:
> 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.
I want the gnu bits to be usable on Solaris as well, but I am concerned
that this proposal will have unintentional side effects down the road:
A) A problem with comparing XPG4 with the gnu stuff is that the
XPG4 bits don't evolve very fast, the XPG4 bits are, in many
cases, derived from the /usr/bin bits (or vice-versa), and
there isn't an external provider of the XPG4 bits. The GNU
bits don't share these attributes.
B) How does this address the issue of "the bits delivered by Sun
are stale and I'd like to refresh them?" Because the OpenSolaris
/usr/bin/gnu project isn't the primary developer/publisher of
these bits, it can not claim to be the only arbiter of when
they get (re)delivered.
Today, the gnu bits are not in /usr/bin, so my environment with
PATH=/usr/bin:/opt/csw/bin
works - giving me the Solaris "posix" bits and the latest
csw-packaged GNU bits.
Now, this proposal adds SFW GNU bits to /usr/bin and "hides"
the ones I was using.
How do I get back to a bleeding-edge, up-to-date set of gnu bits
without having to hack up the filesystem on every system I use
(by making a directory of symlinks...) and without losing the
Solaris "posix bits" (like PATH=/usr/csw/bin:/usr/bin would do)?
Potential Answer: I should stop using the CSW generated gnu
bits in favor of building and using the latest
SFW gnu packages. This presumes that this
OpenSolaris/GNU project keeps those bits up
to date WRT the upstream FSF source, and that
I (as a user) could download/configure/make/install
more recent bits on my own schedule.
Alternative Answer: I no longer can expect to stay current with the
latest gnu bits because their update frequency
has been co-opted by my distro provider.
C) Another problem is that of what actually ends up in /usr/bin. This propoal
makes it "first come, first serve" - put it into /usr/bin as long as
you are the first one there, otherwise put it in a different place. This
gives us - over time - a rather random assortment of "first class"
executables in /usr/bin, with a slew of "2nd class" alternative bits
strewn around in many other places. And, by their nature, these alternative
bits stand a very high chance of conflicting with other alternatives -
Joerg's
example of make comes to mind)
At some future point, we may have:
Posix ls got there first, along with AT&T's make and Joerg's star. This
means that the gnu ls, csw's ls, make and star and the three or four other
versions of make all are forced to live elsewhere. Let this accretion
continue for a while, and we will no longer be able to interpose any
"alternate command environment" without a potential slew of unintended,
unpredicted and undesired consequences.
-John
