Nicolas Williams <Nicolas.Williams at sun.com> wrote:
> I don't want to add to the fire, but I think we can SUMMARIZE the
> situation for AT&T, applications of AST outside AT&T or the OS, and Sun
> as:
...
> b) Solaris has never delivered the AST libcmd before, THEREFORE...
>
> c) ...changing the path of this shared object in Solaris (when ksh93
> integrates) would NOT break binary compatibility but...
>
> d) ...WOULD break source-level/build compatibility for 3rd parties that
> use the AST libcmd and expect it to live in /usr/lib (since it
> wouldn't be found there).
>
> e) Such third parties may or may not exist -- this is NOT clear. Even
> if they do the ARC might consider (d) to be unreasonable.
>From my understanding, the cleanes way would be to out ksh::libcmd into
/usr/lib/ksh/ or /usr/lib/ast/ without merging with sun/att::libcmd.
There is no source issue as you only need to change one consistent source.
There is no binary issue as an updated ksh93 installation would install
a recent libcmd in a location that if searched first by default by the
new installation.
There is no usage/scripting issue as users would not even notice the change.
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
