On Wed, 25 Jun 2008 12:11:51 -0500 "Shawn Walker" <[EMAIL PROTECTED]> wrote:
> 2008/6/25 Mike Meyer <[EMAIL PROTECTED]>:
> > On Wed, 25 Jun 2008 08:15:57 -0700 Alan Coopersmith <[EMAIL PROTECTED]>
> > wrote:
> >> So you're recommending creating a contrib consolidation for these to
> >> be checked into and built from?
> >
> > If he won't, I will. There are a number of reasons for this:
> >
> > - Having a single "blessed" place that it's easy to add third party
> > apps to will prevent people from feeling the need to run their own
> > such repositories, which will eliminate a duplication of effort,
> > storage waste on the client machines, and user frustration as they
> > discover that you can't use foo from repo1 with bar from repo2
> > because baf that they both depend on was built with different
> > options in the two repos.
>
> That's another reason why I don't want to see contributions
> discouraged due to lack of source code access or a good build recipe.
I couldn't agree more. That just means there needs to be standardized
build process that's easy to hook into. The absolute bare minimum
would be a shell script that does everything, but people working on
these things would probably appreciate it if there were well-defined
steps - say fetch sources, extract sources, apply patches, build,
create package - that could be applied individually. They may well be
no-ops if they don't apply - no patches, it's a script scripts, or
proprietary binaries, etc.
> 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.
<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
