Re. http://mail-index.netbsd.org/tech-pkg/2002/05/31/0000.html

Mostly this is an abstract issue for me.  But there are some points worth
commenting on:

The implicit concern about dialup users seems misplaced.  I was a dialup
user until a year ago.  I never found it a problem to wait for pkgsrc
downloads.  Of course, it's all relative...I didn't mind a 1200bps modem
until I got a 14400 modem.  (^&  YMMV, but if the concern about modems is
abstract on your part (the lack of concern is real, concrete, first-hand
on mine), I submit that it's not a real issue.

For a trade-show (unless the *point* is to demo pkgsrc), it seems that you
should be going with binary packages on a CD, yes?  (Assuming that you
can't just bring along your own, preconfigured machine...)

If you want to build some packages from pkgsrc, but don't want to build
Perl, why not install Perl via a binary package?  (You did specifically
object to the trouble of building Perl in order to build other things.)

If you object to having precompiled files installed and want *everything*
from source, why do you want to bypass compiling configure.in?  (Other
than the fact that compiling Perl takes longer than compiling
configure.in, there is little difference---assuming that you don't
personally use Perl any more than you personally use the compiled
configure script..)

Greg also raises the point that if you want to locally change
configure.in, then pkgsrc patches to the compiled output of autoconf will
be lost.  A few years ago, the phrase ``the principle of least surprise''
was commonly bandied about.  To *me*, that means, here, that ``make
patch'' should leave the system in a state where you can apply local
patches to *sources* and then finish building.  If your local fixes
involve modifying configure.in, then you should *not* wind up effectively
undoing the pkgsrc patches someone else made to configure the package.
(Unless that was the intent of some of your local patches.)


Perhaps a legitimate question, though, is: Who is pkgsrc really for?  If
it's for pretty much everyone, then Greg has a valid point.  I think that
the objections others raise against his view can largely be settled with
binary packages, but his point cannot be readily dismissed without simply
dismissing his concerns altogether.  (Providing patches against both
configure.in and configure may be workable.  Greg seems to say that that
would involve massive diff's for the configure patches, though, and
there's the problem of ensuring that the two files are in synch...)


  ``I probably don't know what I'm talking about.'' --rauch@math.rice.edu