On Wed, Sep 24, 2008 at 7:30 AM, James Carlson <[EMAIL PROTECTED]> wrote: > Jason King writes: >> I'm curious to know if there has been any consideration made to the >> external dependencies for building ON (and specifically keeping the >> dependencies limited) when things are integrated. I know ON is not >> self contained, but for example, the integration of mms into ON means >> that libpq (postgres client library) now required to build ON (I don't >> believe that was the case previously). This seems (to me at least) a >> bit much to require a database client library to compile the core >> components of Opensolaris. > > We've always required a _full_ install of Solaris on build machines, > period. > > The ON gate does maintain a list of non-ON packages that need to be > updated when a machine is BFU'd, but I don't think that list is > published externally -- at least I don't see it here: > > http://www.opensolaris.org/os/community/on/ > > In any event, it'd be quite difficult to maintain such a list > accurately, it'd be risky to get it wrong, and it pay-off for doing it > right seems both slight and hard to measure. Why bother trying to > "minimize" build systems? Of the things on which we could expend > scarce resources, this seems like an unhelpful one to me. > > For our own build systems (at least here in MA; I'm less familiar with > the other sites), we install everything and use Live Upgrade to do > upgrades between successive Solaris Express releases. No trickery. > ;-} > > -- > 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 >
The problem is, as far as I can tell, with Indiana (aka OpenSolaris) there's no real concept of a 'full' install. You get a base set of packages, and then install whatever else you want as needed. This base set does not contain everything needed to build ON. I'm not sure installing everything on pkg.opensolaris.org is something that will be reasonable in the future, as more and more packages are added. If the current direction is still for SXCE to go away (replaced by Indiana) at some point in the future, this is an issue. _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code