Alan Coopersmith wrote: > Roland Mainz wrote: > >>> The integration into OS/Net is a requirement for the > >>> "migration". > >> Again, why? I don't see why the ksh93 must be in OS/Net to someday > >> deliver the > >> file /usr/bin/ksh. > > > > Why isn't /sbin/sh then in /usr/sfw/bin/ ? Or /usr/bin/csh ? What about > > /usr/bin/bc ? > > Because those are covered by the compatibility guarantee. /usr/sfw was > intended as the "Use these at your own risk because they can change > incompatibily" directory, but is now deprecated. That's irrelevant to the > question though - ON vs. SFW is only about where software is built, not > where it is delivered. SFW components can be installed in /usr/bin or other > places as needed. > > > An integration into SFW would make it FAR more difficult to convince other > > consolitations to use it and a replacement of /usr/bin/ksh will likely > > become IMPOSSIBLE. > > Why? We all use lots of things from SFW already in the other consolidations.
See my examples in my answer to Dan's email. For example if |libc::workexp()| depends on ksh93 or wants to |dlload()| libshell to do the word expansion it would result in "interresting" effects (IMO an understatement since SMF will fail at boot time - and then all hell will break loose...) when the matching API (e.g. ksh93 and/or libshell) isn't "stable" (or some agreement within Sun has been made (how was that called "Consilidation private"... or "Contracted" ? I don't remeber the exact term exactly anymore...)). The same kind of problem applies to the kernel module for the compiled shell script stuff and many other items (another example: If libast is in SFW - would "perl" be allowed to use it's "sfio" API ?) ... And please correct me I am wrong - the stuff shipped in SFW is not really covered by regular PIT testing, right ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
