Okay, it sounds like there is no problem here then.
I just wanted to make sure what we are specifying in PSARC-EXT/2006/550
was accurate as far as this case.
Thanks,
April
> Date: Fri, 29 Sep 2006 09:04:39 -1000 (HST)
> From: Joseph Kowalski <Joseph.Kowalski at eng.sun.com>
> Subject: Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561
Timeout: 09/05/2006]
> To: Joseph.Kowalski at eng.sun.com, ksh93-integration-discuss at
> opensolaris.org,
April.Chin at eng.sun.com
> Cc: don.cragun at sun.com, roger.faulkner at sun.com, Rod.Evans at sun.com,
PSARC-EXT at sac.sfbay.sun.com, roland.mainz at nrubsig.org
> MIME-Version: 1.0
> Content-MD5: by93unn9gEaBA+wa5bGkPQ==
>
>
> > From: April Chin <April.Chin at eng.sun.com>
> ...
> > If PSARC-EXT/2006/561 specifies that the existing libcmd files be removed,
> > per step (3), the following files would be removed:
> > /lib/libcmd.so
> > /lib/libcmd.so.1
> > /lib/{amd64,sparcv9}/libcmd.so
> > /lib/{amd64,sparcv9}/libcmd.so.1
> > /usr/lib/libcmd.so
> > /usr/lib/libcmd.so.1
> > /usr/lib/{amd64,sparcv9}/libcmd.so
> > /usr/lib/{amd64,sparcv9}/libcmd.so.1
> >
> > There is a pending update to the spec for PSARC-EXT/2006/550
> > which assumes that the ksh93 integration case
> > will deliver only the new AT&T b_*() interfaces to an empty, existing
libcmd.
> > Well, the current version of the spec assumes this as well but isn't
> > as clear on this point.
>
> How does it matter (as far as 550 is concerned) if it delivers the interfaces
> to an empty, existing libcmd or simply delivers a library? All that matters
> as far as 550 is concerned is the final state of the system after 550
> delivers.
>
> Now, you may have valid integration/implementation concerns. If so, please
> just contact me directly and we can work these out.
>
> > These new interfaces are Project Private, so if PSARC-EXT/2006/550 needs to
> > specify adding the libcmd library also, it should also be Project Private.
> > If so, it would only be appropriate to add the libraries
> > /usr/lib/libcmd.so.1
> > /usr/lib/{amd64,sparcv9}/libcmd.so.1
> > and no compilation environment name (libcmd.so), as recommended in the
> > Best Practices doc on Libraries and Shared Objects Requirements:
> > http://opensolaris.org/os/community/arc/policies/libraries/
>
> Libraries (other than the name) don't have an interface commitment level.
> The functions within the library each have an interface commitment level.
>
> Yes, we are violating the Best Practice by mixing taxonomy levels within
> a library. After all these integrations are completed most of libcmd
> will be project private, while the library name and filter entries will
> be Sun Private. Note that even if the def*() routines become Public,
> the filter elements remain Sun Private - the Public elements would be
> only by the direct to libc path. These filter entries *never* change.
> Also note that this mixing of commitment levels has been a property of
> all proposals to date. This isn't new.
>
> I perhaps should have called this out explicitly in my proposal.
>
> > Note that the removal of libcmd.so would be a problem for unbundled
> > or non-ON applications
> > which attempt to compile with -lcmd. Within ON, we're removing -lcmd
> > (ksh93 will be able to compile by finding libcmd.so in the ON proto area).
>
> It is only a problem if no libcmd exists. This was the deciding factor
> in drawing the line between the project phases.
>
> > So yes, I would prefer that PSARC-EXT/2006/561 removed the def*() interfaces
> > and leave a libcmd husk. If PSARC-EXT/2006/561 also moves this libcmd
> > husk from /lib to /usr/lib (the real binaries live in /lib currently,
> > with symlinks from /usr/lib), that would be fine for PSARC-EXT/2006/550
> > but not required.
>
> After talking with Bill, I tend to like this suggestion also. Not for
> any architectural or even integration management reasons, but for testing
> reasons. Moving the discovery of any unforseen problems to phase 1 is a
> good thing (as Roland stands up and cheers!).
>
> I'll repost the proposal shortly. The final state will not be changed.
> Only the line between the two phases will be redrawn. (I suspect we will
> find that phase 2 is now empty (or more exactly, all within 550), but I
> want to take a few minutes to work it out and be sure.
>
> - cheers,
>
> - jek3
>
