[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-arc-discuss
Subject:    [approach-discuss] Re: [arc-discuss] Re: Two (hopefully) minor
From:       sommerfeld () sun ! com (Bill Sommerfeld)
Date:       2006-01-30 12:07:03
Message-ID: 1138650086.10376.40.camel () thunk
[Download RAW message or body]

On Fri, 2006-01-27 at 20:03, Alan Coopersmith wrote:
> This case (PSARC 2005/683) would seem to be a useful one to do since
> it clarifies the rules on when commands in /usr/bin should diverge from
> those in /usr/xpg4/bin or /usr/xpg6/bin.   Unfortunately, the opinion
> is still in draft form so release should probably wait until the final
> version is ready (unless we want to bring the community in on the
> conversation of whether the policy it sets is the right one).

Alan's mention of this opinion kicked me into finishing up the bits
which prevented me from pushing it into the review cycle.

The real meat of the opinion is the following:

   The discussion also exposed significant divergence between our
   standards compliance architecture and its implementation.  In many
   cases, once a decision to "fork" a command was made, many new
   non-conflicting behaviors were integrated only into the xpgN
variants.
   However, as a general rule, there should be no cases where a
   particular command feature, option, or the like accepted by a
   /usr/xpgN/bin variant should generate a syntax error when fed to the
   default system (/usr/bin) variant.

   This divergence has created both confusion about the overall
   architecture,  and  also substantially increases the need to
   cherry-pick specific command variants in scripts.

   This degree of confusion is harmful to Solaris  and  to  our
   users.   When members of the community encounter such diver-
   gence, they should file bugs against the commands  in  ques-
   tion,  and  should  flag  those  bugs with the "missing-std-
   feature" keyword.

To the extent that reviewers have taken issue with this, it's been
either (a) a matter of resource allocation (is time better spent doing
something else instead of fixing these problems?) or (b) exactly where
the boundary lies.

					- Bill








[prev in list] [next in list] [prev in thread] [next in thread]