[ksh93-integration-discuss] Re: [osol-code] ksh93-integration prototype004 2007-01-27 webref+diff

[James Carlson]

Roland Mainz writes:
> It's not "enougth" because Solaris gurantees some kind of API stabilty
> once there are *.so files and lint libraries around (or better: Read
> http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2007-February/002179.html
> , James is much better at explaining the issue... :-) ).

Actually, it's a bit the other way around.  We allow and expect *.so
links and lint libraries when the library is stable and publicly
documented.  If it's not, then you need a _really_ good explaination
of why you need to ship these things.

> A possible excape route may be to create something like a
> "SUNWastprivateplayground" package which provides the private API
> add-ones as a seperate package stored at the project website... would
> that be allowed ?

If it's actually useful for somebody and not a distraction, then I
think that'd be reasonable.  In fact, it'd be better if such a package
were part of the WOS but not included in any metacluster (as, for
example, most of the SUNW.*S source code packages are).  That's
"better" if those customers are independent and expected to get just a
distribution install medium.

I suspect, though, that it's just a distraction, and what those users
actually need is either the source code on which to hack (which we're
publishing separately and which they can get from AT&T), or they need
the _stable_ libraries (for which they simply must wait).

In other words, I don't see the convincing usage case that's solved in
this way, but not solved better by the use of the source repository
itself.

Roland Mainz writes:
> > I'm confused.  If these APIs are not public, then people should not be
> > playing around with using the APIs except in the context by which
> > they're ARCed.  If they're Project Private, then only the ksh93 project
> > inside the ON consolidation may use them.
> 
> What about "contracts" between individual projects, e.g. dtksh vs. ksh93
> in OS/Net or dbx vs. ksh93 in OS/Net ? Would that be a justification to
> ship the lint libraries (I guess the answer is "no") ?

If there were such contracts, then you'd have to come up with a way to
make good on them.  That'd be a matter for you to discuss with your
peers at the other end of the contract.

One way to do this is with a special "SUNWon.*" or "SUNW.*int"
package, such as "SUNWzoneint."  We have packages that aren't
delivered to the WOS at all, and which are used for
cross-consolidation dependencies.

In general, though, if it's possible to avoid a cross-consolidation
dependency, you should.  They're tough to manage over time.

> Alternatively we could create something like a
> "SUNWastprivateplayground" (e.g. "AST private API playground") package
> which provides the private API add-ones as a seperate package stored at
> the project website...
> ... would it be allowed to have the package build pieces for such a
> thing in usr/src/pgkdefs/ (e.g. we built the package but do not ship it
> with Solaris nor ARC it (for now)) ?

Likely, yes, as long as you can convince folks that it's immediately
useful, and not just a solution out looking for a good problem.

-- 
James Carlson, Solaris Networking              <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