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 ... We can and do have dependencies on things in /opt. That's not _necessarily_ a problem. 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. 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. -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677