Dan Price writes: > It is possible that libcmd could be a forcing factor for inclusion > within ON, but you've not articulated any architectural reason that > solaris:libcmd.so can't be transformed into solaris:libcmd_private.so, > have overstated the difficulty of such a change, and anyway, it seems > like the tail wagging the dog.
I think the original rationale here was that the libcmd we've now got is basically a progenitor of the libcmd now in ksh93. So, the question is whether to fork (why?) or to upgrade the library in place. Upgrading certainly has some attraction to it, though the whole built-in issue (POSIX-purity-test versus Solaris-compatibility) has been a bit of a distraction. Alan Coopersmith writes: > You can preserve binary compatibility without doing a full merge. > Move the old one to libsuncmd.so.1 and then add filter entries to > the mapfile for the ksh libcmd.so.1 to redirect users there. > If nothing else it's easier for others to build their own ksh > binaries and retain this compatibility, since they won't need to > copy in the Sun libcmd sources. I like that idea; it should minimize duplication while allowing the new libcmd to be delivered separately. -- 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
