* Darren J. Moffat <Darren.Moffat at sun.com> [2006-12-14 06:31]:
> Over all I completely support this case and have suggested pretty much
> the same thing in previous discussions.
>
> The one area I'm a little uncomfortable with is the position on new
> 'g' variants in /usr/bin.
>
> Having these is actually very helpful and some software is written to
> look for them explicilty since it knows it must use a GNU tool but
> wouldn't otherwise be able to find them.
>
> One such tool is /usr/bin/hgmerge. It knows it depends on
> functionality in the GNU diff and patch tools and looks for them as
> gdiff/gdiff3/gpatch first then as diff/diff3/patch.
>
> If we were not allowed to create /usr/bin/gdiff{3} [ /usr/bin/gpatch
> already exists ] then it would require that /usr/gnu/bin be in the
> users path for hgmerge(1) to work as designed.
> Now maybe we could patch hgmerge(1) to look for /usr/gnu/bin/diff{3}
> rather than gdiff but the point is that this is existing code that
> arrived in OpenSolaris unchanged that knows about the 'g' variants.
>
> For that reason alone I think there is value in allowing cases to
> provided additional 'g' variants in /usr/bin. However I don't believe
> we should require them just don't explicitly disallow them.
The language in Section 2.4 is supposed to discourage arbitrary
introduction of 'g'-prefixed commands. The exception I hoped was
clear:
In cases where another operating system has provided a
'g'-prefixed variant, the project team introducing an
otherwise-name-conflicting GNU component may choose to also
provide one; otherwise, additional 'g'-prefixed components in
/usr/bin (or any other path) are discouraged.
We could generalize the "another operating system" condition, if you
like. I don't want "gls", "gcat", etc.; I do want "ginstall"--as the
coreutils case introduces (from a similar line of reasoning as your
case above).
- Stephen
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com http://blogs.sun.com/sch/
