James Carlson 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.
>
With the new OpenSolaris installation method, the notion of a _full_
install is not quite the same as what it used to be. It sure would be
nice to have a concrete description of what is required to build ON on
an OpenSolaris (as opposed to SXCE) distribution.
There remain other OpenSolaris-specific build bugs, as well. Hopefully
they are getting resolved.
-- Garrett
> 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.
> ;-}
>
>
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
