Roland & James have already replied, so
I'll try not to be redundant. I have just a few in-line comments, below.
April
> Date: Wed, 17 Jan 2007 10:32:27 -1000
> From: Joseph Kowalski <jek3 at sun.com>
> Subject: Re: 2007/035 ksh93 Amendments
> To: James Carlson <james.d.carlson at sun.com>
> Cc: psarc-ext at sun.com, "April D. Chin" <april.chin at sun.com>
> MIME-version: 1.0
> Content-transfer-encoding: 7BIT
> X-PMX-Version: 5.2.0.264296
> User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
>
>
> There are a couple of things I don't understand about this proposal.
> I'm not
> suggesting a change, simply additional rationale/clarification.
>
> James Carlson wrote:
> > The stability of the getconf built-in command-line interface and the
> > system variables documented in getconf(1) is Committed; its pathname
> > binding to /bin is Volatile. The getconf built-in supports additional
> > system variables not available for /usr/bin/getconf; these variables
> > are Project Private, and include names prefixed with "AST" and "_AST".
> >
> What does "its pathname binding" actually mean and is it /bin or /usr/bin?
I started to write an explanation of pathname binding...but please
refer to Roland's email...
At some point, (but, given the conflicting requirements
of /usr/bin/getconf vs. xpg4 and xpg6 standards, maybe never),
the pathname binding of the ksh93 getconf built-in could go away.
No pathname binding would mean that executing "getconf" without a
pathname prefix would always execute the getconf built-in, regardless
of $PATH.
> > These components will initially be used only by the Korn Shell 93
> > Integration Project (PSARC/2006/550). The proposed location of the
> > tools in /usr/ast/bin is consistent with the location used within
> > AT&T.
> >
> Ah, battling communities - my favorite.
>
> We get some degree of flack from the Linux FSH crowd about creating project
> specific directories in /usr. The charming FSH spec simply says, "don't
> do this"
> without saying what to do. It seems like the standard response is to
> put such things
> either in /opt (reasonable, but a problem for Solaris diskless/zones) or
> under /usr/lib
> (completely silly in all respects, IMHO, it just moves the problem to
> another
> directory, one that is repeatedly scanned by ld.so - go figure).
>
> I guess if ksh93 installed on a Linux system installs into /usr/ast,
> with the resultant
> wrath of the FSH zelots, we have no problem. If it installs elsewhere,
> we need to
> have the discussion as to if we should be like Linux or be like legacy
> Solaris.
Linux may install these utilities under /opt/ast,
but this does not work for us because on Solaris,
/opt is for unbundled products only, and the AT&T
messaging components will be bundled. They are required for the ON
build for ksh93, so they must be installed onto build systems.
>
> Aside: For those who don't know, I personally view the FSH document to
> be one of the
> worst specifications ever created, but there are zelots out there who
> think it was
> written on stone tablets. Sigh,...
> > If the interface stability level of the shared libraries listed in
> > PSARC/2006/550 (libshell, libast, libdll, and libcmd) is promoted from
> > Project Private, the stability of the /usr/ast/bin components listed
> > below should be promoted to at least the same level, to allow
> > consumers of the former to build the appropriate message files.
> >
> This isn't declarative. It starts with "If". Are the promoted, and if
> so, to what?
>
> Volatile I guess, but it needs to be explicit.
> > Interface Description Stability
> > --------- ----------- ---------
> > /usr/lib/libpp.so.1 AT&T ANSI C preprocessor library Project Private
> >
> Why is this interesting to list? (No harm, but I fear I might be
> missing something.)
> > A new package for AST (Advanced Software Technology) developer tools,
> > SUNWastdev, will be created, which includes all of the above
> > message-building components. These tools have a dependency on ksh93
> > and its libraries, as listed in PSARC/2006/550, and shall not be
> > integrated before the Korn Shell 93 Integration project.
> >
> What Metacluster is this package to be added to?
We would like to add this to the Developer cluster, since it needs
to be installed onto build machines.
>
> - thanks,
>
> - jek3
>
