On Thu, Aug 10, 2006 at 07:22:41AM -0700, Garrett D'Amore wrote:

> In my opinion, if a library is required to build ON, then it should
> probably be moved into ON.
> 
> This might mean that libxml should be moved.

Yes, and most people I've talked with about this have agreed.  There
have been at various times efforts to do this but it hasn't happened.

I also think Net-SNMP (really SMA) should live in ON for similar
reasons; after all, SEA has lived there for years and provides the
same type of core functionality.

> If it were moved, then the autoconf code could be removed and replaced
> with hardcoded Makefiles.  It probably wouldn't be too hard.   This is
> the way the BSDs have been doing thing things for years now. :-) 
> (Except they call "on" either "base" or "core" and the other bits go
> into "pkgsrc" or "ports".)

Yes, and this is the approach I'd like to see us take for all
"strategic" externally-sourced components and as many of the
nonstrategic ones as we can find people willing to do the work.
Unfortunately it's expensive and does not deliver immediate and
obvious benefits to Sun's paying customers, so convincing people at
Sun that it's worth doing has been a challenge to say the least.  It
does, however, deliver a notable improvement in product quality and in
some ways makes engineering easier, so perhaps OpenSolaris will make
it possible in spite of Sun's priorities.

For this to work, we need to get away from the idea that everything
has to be updated continuously.  It doesn't.  What's needed is the
ability to bring in needed pieces of functionality at the right time,
which requires a full understanding of both the existing and new code.
A model that emphasises frequent, inexpensive updates and staying
close to the upstream source - which likely relies on autoconf and has
other undesirable artifacts, no matter how involved we may be in its
development community - is incompatible with this requirement.  That
is, instead of offering "libxml 5.6.6" as a feature of an
OpenSolaris-based distribution, we would shift to offering "an XML
parsing library with (X,Y,Z) interfaces, the subset (X,Y) of which are
compatible with those found in libxml 5.6.6."

But even if you think we should never fork the actual implementation
of an externally-sourced component, there's not a lot of incentive to
keep using their miserably broken build subsystems.

-- 
Keith M Wesolowski              "Sir, we're surrounded!" 
FishWorks                       "Excellent; we can attack in any direction!" 
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to