> 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
