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 <[EMAIL PROTECTED]> 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 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
