Jason King writes: > There are bits required that aren't redistributable (thus needing the > packages off an SXCE iso). I know there are plans to create a > repository hosted by Sun for those bits, but even once that's there, I > don't think the issue goes away. The current solution would be to > install everything from both repositories. As pkg.opensolaris.org > gains more and more packages beyond what you see in SXCE today, I > really question if 'install everything' is going to be a reasonable > answer. I'm also not sure that I agree that it's an Indiana issue -- > to me it's a lack of specificity
No, it's an Indiana issue. For doing ON builds on SXCE, the answer is quite simple and specific: install everything on that DVD. For the OpenSolaris distribution, I agree that the answer will have to be much more complex, partly because the notion of "everything" has become much slipperier, but also because the installation expectations are fundamentally different. Perhaps they'll have a special package (like "entire") that you can install that will drag in all the current dependencies required to build ON. That sounds like a nifty way to solve the problem, but since it's really an OpenSolaris distribution issue, I do think you ought to discuss the mechanism used to solve the problem there. > All of the required packages have been identified (for the source tree > as of Saturday morning). That list is is a little surprising (for > example, requiring a database -- postgres -- be installed). My > original question (restated, perhaps a bit clearer) is going forward, > is there any attention being paid about putbacks that bring in new > build requirements? Indiana is just probably the best example of why > this is needed. Just saying 'oh well yeah we added this code to ON > and to build it, it requires bash, staroffice, mysql, scheme, tcl, > and gnu/tls, but that's someone elses problem' just doesn't sit well > with me. I'd rather there at least be some sort of heads up about > such things, so that the interested parties (such as the indiana team) > could then update things as appropriate. Right now, things are simple: you can rely on ON consolidation build machines having all of SXCE installed, and (besides obvious things such as compilers) nothing else. Other consolidations have other rules; many of them require packages beyond what's on SXCE due to the use of private interfaces. You have to read the documentation for *each* consolidation if you want to get the full story. For Indiana, it gets more complex. I think that the Indiana team will have to work with each of the consolidation owners (it sounds to me like you're talking about ON alone, but OpenSolaris is much, much bigger than just ON!) to determine a workable solution. It'll need to be something that their packaging system can handle, and something that's feasible for the C-teams to enforce. I personally don't want to design that solution, and I don't think this is the right venue. If you do, then I suggest (again) getting in touch with the Indiana team and probably the community groups and projects related to the various consolidations. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 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 opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
