(This message will probably be delayed to some lists because I'm not a
subscriber to either indiana-discuss or caiman-discuss)
On Thu, 2007-11-01 at 10:08 +0100, [EMAIL PROTECTED] wrote:
> The GNU environment would be "GNU compliant"; and not at all related
> to other standards. Some people apparently want the GNU tools and fixing
> them to be POSIX compliant might actually break them for those customers.
I wouldn't be so quick to dismiss Irek's concerns.
(As a reminder, /usr/gnu/bin is an intentionally sparse tree, containing
variants of commands that explicitly conflict with ones in /usr/bin).
If a "GNU compliant" environment were to become a first-class or default
environment on solaris (in other words, if we expect a significant
fraction of users to put /usr/gnu/bin in $PATH), I'd think that a
logical extension of the precedent set in PSARC 2005/683 (which added
crontab variants to /usr/xpgN/bin) might be in order, resulting in a
general mandate to add non-conflicting GNU-compliant extensions to
the /usr/bin variants of tools found in /usr/gnu/bin.
As a reminder, 2005/683 clarified the intended relationship between
variant commands found in /usr/bin, /usr/xpg4/bin, and /usr/xpg6/bin.
Past practice was that, once a single conflict between the governing
specifications forced a "fork" there was no subsequent attempt to
minimize the difference between variants -- so a new option introduced
for xpg6 compliance which was a syntax error in the /usr/bin variant of
the command wouldn't necessarily added to the /usr/bin variant, while
solaris-specific extensions which did not conflict with the standard
wouldn't necessarily be added to the xpg6 variant. This forking renders
both variants of the command less useful.
2005/683 said that, to the greatest extent permitted by the various
standards we comply with, divergence between different command variants
should be minimized. Given the somewhat greater divergence between the
GNU commandset and traditional solaris, doing this for a GNU environment
is a somewhat bigger step.
I'll note in passing that this collides headlong with the recommendation
in 1999/645 (CLIP) that we not bother adding long options to core unix
commands. But the very creation of /usr/gnu/bin also conflicts with
that recommendation.
I'd think that the path of least resistance would involve using the GNU
codebase for /usr/bin and /usr/xpgN/bin variants, in the process fixing
up the very posix compliance issues that Irek complains about -- just
not in the /usr/gnu/bin variants.
- Bill
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
