Re: Various size of (Project) ideas for NetBSD and pkgsrc

[Marc Espie <espie%nerim.net@localhost>]

Seeing the next messages on the discussion, I'd also like to point
out a common fallacy and vicious circles.

People will say that MULTI_PACKAGES are useless, because different
people need different options, and so you have to rebuild stuff
anyways, so they're useless.

Actually, that's a vicious circle. People need different options
as long as binary packages don't exist.

If you don't have a reliable way to provide a consistent set of
binary packages on a regular basis, then of course, people get in
the habit of building their own, and of putting their special need
in front.

Standardizing builds, focusing on specific release policies, and
providing binary packages, WILL put further pressure on cleaning
things up.

Suddenly, you have standard packages that people can use, can test,
can rely upon, and things that deviate from that norm take extra
effort to build.

Yep, that means going into the "binary vendor" business.

But really, once you have basic reliable binary packages, that's
such a comfort that: 
- some people will discover they don't really need umpteen options; 
- there will be some effort to turn previous compilation-time 
configuration into run-time switches.

Again, this is something we've seen happen again and again in
OpenBSD-land.  We've managed to keep things *very* simple for the
user who wants to build stuff by hand, but the actual official
binary package builds are the real focus, as far as quality goes.

That's obviously a choice.  The only way to know whether it works
for you is to try it out.

Citing various pieces of software as examples of why it can't work
is unscientific.

Speaking from past experience, the gross majority of a ports tree
is amenable to MULTI_PACKAGES. And in many of the remaining cases,
once you've done the first 80% or so, you'll find that people are
willing to work quite hard to tweak the remaining 20% to build in
more efficient ways.