* Bill Sommerfeld <sommerfeld at sun.com> [2006-05-02 08:27]:
> On Mon, 2006-05-01 at 14:15, Stephen Hahn wrote:
> > | A new directory hierarchy, to contain otherwise-name-conflicting GNU
> > | utilities under their original names, is proposed. A guideline for
> > | the provision of 'g'-prefixed variants in /usr/bin is also
> > | presented.
>
> What is the definition of "GNU" you're using here? /usr/xpgN have a
> very clearly defined "authority" (the specs), but GNU is as least
> sometimes used in a much less precise way.
I was using the "FSF/UNESCO Free Software Directory" listing...
> Basically, if someone says "I want to integrate XXX into /usr/gnu", and
> it conflicts with the existing /usr/bin/XXX in some way so isn't
> eligible to go into /usr/bin, what's the acceptance criteria which an
> ARC would use to determine if XXX is *THE* gnu variant of XXX? ("Listed
> in http://directory.fsf.org/GNU/"; perhaps? is that a large enough set
> of packages?)
... which is this very list. I believe that, if we are going to treat
the GNU tools as a specific environment, we need to use some form of
specification--this directory appears appropriate. If the candidate
tool isn't on it, and conflicts with /usr/bin, and isn't appropriate
for Companion inclusion (because it's too important), then I think
we're back to the prefix-or-hierarchy case Danek mentioned.
> As a second note, I suggest avoiding the use of the term "version"; I
> used "variant" fairly consistently in the 2005/683 specifically to avoid
> any confusion with things like the release-number-versioning of
> particular tools.
Will fix; "variant" is much better.
- Stephen
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com http://blogs.sun.com/sch/
