> Subject: Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] > From: Bill Sommerfeld <sommerfeld at sun.com> > To: Joseph Kowalski <Joseph.Kowalski at eng.sun.com>, Korn Shell 93 integration/migration project discussion <ksh93-integration-discuss at opensolaris.org> > Cc: PSARC-EXT at sac.sfbay.sun.com, Rod.Evans at sun.com, roger.faulkner at > sun.com, don.cragun at sun.com, roland.mainz at nrubsig.or > Date: Fri, 29 Sep 2006 11:07:13 -0400 > Mime-Version: 1.0 > Content-Transfer-Encoding: 7bit > > On Thu, 2006-09-28 at 19:03 -1000, Joseph Kowalski wrote: > > This project explicitly requests permission to integrate as multiple > > putbacks. Steps 1) and 2) are allowed to integrate separately from > > the subsequent steps. Steps 3) and 4) must happen monolithically and > > logically as part of the ksh (1993) putback. It seems unreasonable to > > burden an OpenSolaris originated project with steps 1) and 2), particularly > > as some instances of -lcmd may be in closed source. > > What's the state of libcmd after part (1) delivers? is there a reduced > husk of a libcmd which acts only as a filter to libc for the def*() > functions it formerly implemented, or is it left intact with a second > copy of the functions?
The state of libcmd after part (1) isn't specified, because it doesn't matter. It could be simply untouched or it could be the minimal filter you suggest. Is there any architecure associated with this? > Unless all four parts are delivering together, it seems like it would be > better to deliver the filter-only library as part of part (1); part (4) > would conceptually add the ksh93-delivered libcmd to the empty husk, and > part (3) (atomically part of part 4) would essentially disappear. Kinda, The filter in part (1) would be in /lib, part (4) would also have to move it to /usr/lib. Unless you feel there is real architecture here, let's take this discussion off line. If anything comes from that, we can post the summary back to these broad aliases. - cheers, - jek3
