Subject: Re: CVS commit: pkgsrc/net/mtr
To: NetBSD Packages Technical Discussion List <tech-pkg@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-pkg
Date: 10/25/2001 16:56:56
[ On Thursday, October 25, 2001 at 15:15:35 (-0400), Jim Wise wrote: ]
> Subject: Re: CVS commit: pkgsrc/net/mtr
>
> 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,
> silly.
I did not suggest doing either of those "silly" things....
(though I personally wouldn't object very much to the latter, especially
not if there were customised pkg-auto* tool variants to use....)
> It is a standing policy of pkgsrc that when you patch configure.in, you
> regen configure, and commit a patch to configure based on the result.
That's not borne out by the evidence in pkgsrc today.
That might be how you think it should work, but it's definitely not how
I think it should work. Besides being a direct violation of the "never
commit a generated file" rule, it's also an illogical and unnecessary
complication to the pkgsrc patches.
> 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),
I don't think you've thought through the process completely.....
Yes it is a twisty little maze of passages all alike, and there are many
dead ends where local patches to build procedures cannot win without
also making adjustments to the pkgsrc components themselves (at least
that's the case until/unless auto* are indeed always run).
> 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.
1) submit your pkgsrc changes to the package's build procedure back to
the author
2) bite the bullet and eat the cost of running auto* with every "make"
until the package's author accepts the changes (they really are not
that expensive to run, especially not compared to the cost of
actually running the generated configure script!)
Do not second guess auto* and do not assume that further changes might
not be made by local pkgsrc patches.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>