> From: James Carlson <james.d.carlson at sun.com> ... > > That said, I don't see a reason that *either* libcmd should become > > Public. > > That's the sticking point. The others commenting on this thread have > said that they expect third parties to join in on the libcmd fun: > > Don Cragun said: > > > Not in this PSARC case. TBD for a future case. > > David Korn wrote: > > > Most shell plugins should go in .../lib/ksh/plugin.so but libcmd.so > > is different since it is not just usable by ksh. We have > > nearly 40 other commands that use this library and changing the > > location would not work for other systems that also use these commands. > > Roland Mainz contributed: > > > The current design was made with LOTS of thinking and we already had a > > bitter debate&&fight over this issue (and I already pointed out that > > exactly this bitter debate nearly destroyed the project). There isn't > > really another option except blowing one side of completely up - and I > > will not let that happen. > > So, clearly, the project team appears to believe: > > - that libcmd.so needs to be in /lib or /usr/lib > > - that there will be applications outside of ksh that will link to > this library in order to avoid fork+exec or spawn overhead > > - that some of those applications will be portable across machines > other than Solaris, and thus it'd be bad for us to rename the > library > > None of that sounds like Private to me, though I'd still very much > like to see this library *be* Private.
But it doesn't sound Public either. David Korn's comment must be at a source level. Yep, this would require a minimal fork from those sources. Considering the compatibility issues, in a couple of months, this fork will be lost in the noise. - jek3
