Subject: Re: CVS commit: pkgsrc/net/mtr
To: NetBSD Packages Technical Discussion List <>
From: Jim Wise <>
List: tech-pkg
Date: 10/25/2001 15:15:35
Hash: SHA1

As my two-year-old would say `Hi!  You're silly!'.

Simply excluding a large number of packages from pkgsrc because we don't
like the tools the author used to generate their configure scripts is
just that -- silly.  Likewise, endlessly rerunning automake and autoconf
on inputs which haven't changed (and which we've cryptographically
hashed to make _sure_ they haven't changed, fer chrissakes) is, well,

It is a standing policy of pkgsrc that when you patch, you
regen configure, and commit a patch to configure based on the result.
Doing so not only _doesn't_ make local changes harder (unless you're
editing the contents of ${WRKDSRCDIR} by hand, in which case you
Deserver to Lose), it also, as pointed out at the beginning of this
thread, saves people on slow machines from endless and meaningless
installations and invocations of autoconf and automake.

And on that note, I'm taking off my grumpy hat and going to get a cup of

On Thu, 25 Oct 2001, Greg A. Woods wrote:

>[ On Thursday, October 25, 2001 at 11:14:08 (-0700), Johnny Lam wrote: ]
>> Subject: Re: CVS commit: pkgsrc/net/mtr
>> The above isn't's just an idea, but perhaps we can rework it
>> to something usable, or come up with something better?
>People who build packages should expect to have all the package building
>tools installed, and if that includes automake, and thus perl, then
>that's the way it is.  If you don't like it then don't "support" tools
>which require such top-heavy build systems.  Life's too short to worry
>about such silly things, especially when hard-coding the patches makes
>further local patching impossible without undoing a lot of the

- -- 
				Jim Wise

Version: GnuPG v1.0.6 (NetBSD)
Comment: For info see