On Wed, 25 Jun 2008 12:53:32 -0500 "Shawn Walker" <[EMAIL PROTECTED]> wrote:
> 2008/6/25 Mike Meyer <[EMAIL PROTECTED]>:
> > On Wed, 25 Jun 2008 12:11:51 -0500 "Shawn Walker" <[EMAIL PROTECTED]> wrote:
> >> The value is in the ecosystem, not in the build process.
> >
> > The build process can help to contribute to the value of the
> > ecosystem. In particular, if the build process is such that the only
> > possible build is the one the contributor provides, then this directly
> > detracts from the ecosystem to anyone who needs something different
> > from that build. If you provide a standard set of switches that the
> > user who wants them can set (or let the build process autodetect) to
> > build something slightly different - GNOME or KDE or neither? Emacs or
> > Xemacs or Eclipse support? Always build the Python/Perl/Ruby/Lua
> > bindings? Python/Perl/Ruby/Lua install to build for? Compiler flags to
> > use? - then the value of the ecosystem gets multiplied by the number
> > of knobs and how well they work, as you get to use that one API to
> > build customized versions of anything in the consolidation. The tricky
> > part is to manage to do this without overwhelming the contributor with
> > details that aren't relevant to what they're doing.
> I don't want to get into a "glass half-full" vs. "glass half-empty"
> approach to contributed packages.
I don't think that's the question. It's more a matter of whether
you're going to provide a glass that can only be half full, or one
that someone who's interested in doing the work might be able to fill
to the top.
> While I understand and agree with what you are saying to a certain
> extent, having *a* package positively adds to the ecosystem even if it
> is only available in one build configuration or for one architecture.
Right. That's what the last sentence is all about: you want to provide
the mechanisms that let people who want to provide all the knobs do
so, *without* discouraging people who don't care about them from
contributing packages to the build process.
> Yes, it will be unfortunate when a particular package is only
> available for one architecture or in one build configuration, but just
> having the package is almost always more valuable than not having one
> at all.
I'm not talking about what packages are provided, I'm talking about
what the build process will allow the advanced user to create. So long
as the build process is well-designed and easy to use, there's not
really any reason to have provide any package configuration other than
"turn on everything."
An ecosystem that doesn't pretty uniformly stay up to date has little
or no value. All you've done is exchanged the problems of clashes
across repositories with clashes across builds. While the build system
itself has no value to most end users, one that makes it easy to keep
the available set of packages up to date across all supported builds
will make delivering an ecosystem that retains it's value easy, and a
build system that makes that hard will make delivering such an
ecosystem hard.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
