James Carlson wrote:
> Roland Mainz writes:
> > > how about an FHS /opt/ast prefix?
> > > it would have a better chance of matching ast package
> > > installations in other systems
> >
> > Erm... yes. The "tricky" part is that we add ksh93&co. to the base OS.
> > I'm not sure whether people (such as PSARC) will be happy to see a
> > dependicy to /opt (which is AFAIK for "optional" packages) ... that's
> > why I picked /usr/ast/ (it's in /usr, currently not used by Solaris and
> > we don't create any files in there (yet!) so we're 100% on the "safe"
> > side) in my upcoming patch...
>
> I'm still a bit baffled by the need for a reduced-functionality
> 'uname' utility, but setting that issue aside for a moment ...
Erm... the idea was to have something which exactly implements the POSIX
standard to avoid that script hackers start to rely on non-standard
extensions (<rant>beside that point I just found a serious i18n issue in
/usr/bin/expr (which counts bytes) which seems to be fixed in
/usr/xpg4/bin/expr (which counts characters (think about multi-byte
characters and you have a serious problem)), but that's another story
for another day once shell-discuss at opensolaris.org is up and
running...</rant>) ...
> We can and do have dependencies on things in /opt. That's not
> _necessarily_ a problem.
Yes, but having these pieces in /usr may IMO be better... /bin/ksh (and
possible consumers of libshell.so, too) sits at a very low level of the
OS and runs early at boot time and /opt is something which usually comes
later... much later... so scripts should not start to have something
like /opt/ast/bin/ in their ${PATH} just to be able to use the
builtins...
> Fortunately, PSARC consists of engineers.
:-)
> Explain exactly how the dependency works, why it's required, what it
> means for users, and how you plan to manage change across the
> dependency.
Ok...
> If you're able to do that in some reasonable way, and the plan you
> have doesn't lead to obvious (or perhaps not-so-obvious) failure modes
> for users, then it's not an issue. Don't focus too heavily on the
> path names. Figure out the required functionality and delivery issues
> first.
Did you see the patch in
http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-May/000346.html
yet ? AFAIK it should address all compatibility issues cleanly and keeps
all the builtins accessible (with the exceptions of "getconf" and the
recent ACL extensions in "chmod" (which I am going to address before the
putback (assuming we can get rid of the xx@@@!!-license issue, otherwise
I just comment the matching lines out in the builtins listing))).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
