I don't think that's enough; I think point 4 has to be abandoned altogether. Here's why:
* some OSS libs don't bother much about backwards compatibility at the binary level * the libs that _are_ part of supported [Open]Solaris need to be stable more than they need to be the latest and greatest. In particular, they need to satisfy the requirements of other Sun supported software (whether software that Sun controls or leads the development of, or whether software that Sun supports but isn't the lead on) at the versions corresponding to any given Solaris release. That is, while stuff like JDS should ideally not fall incredibly behind, it probably shouldn't be on the bleeding edge * however, a lot of OSS that there may be demand for as part of the companion software tends to have dependencies on the latest libs as of when it was being developed It sure would be nice to push out some discipline back to the various OSS projects, so as to keep the conflicting dependency requirements from exploding; and perhaps that can be done in cases where Sun or other OpenSolaris participants have some influence. But that probably won't cover everything. So I don't see how duplicate libs can be avoided. I think in this regard, Blastwave may be on the right track, for the most part. They worry mostly about their own consistency, and depend on relatively few Solaris libs, generally stuff that doesn't duplicate non-OpenSolaris OSS libs; that decouples their update cycle from that of Solaris. Now I am inclined to think that there is some validity to point 3, in which case there would likely be new versions of at least some libs and commands for the current version of Solaris, rather than Blastwave's approach of using libs compiled on the oldest supported version of Solaris as much as possible, with newer ones for newer versions only when really necessary. I don't think that necessarily needs to be either/or; probably some libs are stable enough that there wouldn't be any reason to rebuild them for each new version of Solaris. To have all the above, be reasonably current (say a few weeks slower than Blastwave's best turnover), and incorporate a perhaps higher level of quality control and testing (so that non-building/testing users could have high confidence in what they downloaded), will definitely require a lot of work, but also a highly effective, well managed, disciplined, and yet distributed overall process. The existing freeware site's package maintainers collectively have a lot of experience building various software; and they have perspectives on dependency issues and build procedures that (hopefully) satisfy their particular objectives. But I think Sun could contribute a lot in terms of process, leadership, quality control practices and techniques, and so on. What's the real need for point 4 (regarding duplication - granted that it's _desirable_ where it's an acceptable tradeoff, in that it simplifies troubleshooting, makes more effective use of memory, probably saves some I/O, etc)? What other potentially mutually exclusive issues are there? This message posted from opensolaris.org
