On Fri, 2006-05-05 at 19:57 +0200, Rainer Orth wrote: > I think there are two arguments in favor of my approach to keep GNU > packages with conflicting parts completely below /usr/gnu: > > * As we've observed a couple of times, several long-time/hardcore > OpenSolaris are purists who would like to stay away from the GNU > command > set as far as possible. This may partially be just religion, but > has a > foundation in ... > > * ... the fact that often GNU maintainers care much less then they > should > about backwards compatibility: observe e.g. the case of coreutils > where > on one hand the maintainers regularly change output formats of > commands > at their whim (ls is an example, since the exact format isn't > prescribed > by POSIX.1), while on the other hand being anal-retentive about > standards > compliance to the point where they remove support for legacy option > even > in cases where POSIX.1 still allowed them (stuff like head -1 being > removed in favor head -n 1), which caused lots of uproar in other > parts > of the GNU community (e.g. GCC where lots of scripts started > breaking > unnecessarily on systems that happened to have recent coreutils > installed). It took quite some time and long and heated arguments > to > have this at least partially resolved, so I can fully understand a > desire > to stay away from such a moving target if possible. To put this in > perspective, I've historically provided the GNU commands for our > users in > /vol/gnu/bin, which is prepended to PATH, to provide a common > cross-platform experience for Solaris, Tru64 UNIX, IRIX (and before > that, > even AIX and NeXTstep). In recent years, I've become quite > reluctant > to update those commands due to those incompatibilities.
Well, both of these arguments seem to be in favour of the /usr/sfw approach: users have to explicitely add these interfaces in various search paths to be found. Laca
