Subject: Re: BUILD_DEPENDS on autoconf
To: NetBSD Packages Technical Discussion List <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 05/30/2002 18:42:45
[ On Thursday, May 30, 2002 at 23:43:06 (+0200), Alistair Crooks wrote: ]
> Subject: Re: BUILD_DEPENDS on autoconf
Not silly at all.
> Forcing everyone to have Perl installed on a build machine is
> a huge cost.
You still have not answered my question as to how you measure this cost.
I don't see it to be huge at all, especially not when compared to the
overall convenience offered by pkgsrc.
Nobody's mentioned how likely it is that any pkgsrc user will get very
far without needing perl for runtime dependencies, let alone for the
very few packages that need (or will ever _need_) autoreconf or automake
to be run before they're built. I maintain the likelyhood is extremely
> I have slow i486 boxes, and ss2s, upon which it takes
> significant amount of time simply to build Perl. Having access to the
> Perl source is another significant factor.
I've built Perl-5.6 on an SS-1+, never mind also on my SS2. It was not
painful or costly -- just slow, but then that's the general "cost" of
running such "older" hardware. Long ago I though the SS2 was a pretty
fast little bugger -- nothing to be sneered at even for building massive
things like all of X11, etc.!
On the other hand most of my builds these days are done on well endowed
P-II/300 (for i386) and SS20 (for sparc). I then create binary packages
and install those on the other slower machines. However I do this
_only_ because I'm impatient, not because it's "painful" or "costly" not
to. (well, I also do it so I can test binary packaging, since I also
use binary packages to maintain software on production machines that are
even bigger and faster than the build machines, but which are not
intended to support software development)
I.e. I have little or no sympathy for someone who chooses to use pkgsrc
on a slow ancient machine and then complains when a generalised build
and dependency maintenance system of this complexity needs to install
some additional tools in order to do a particularly tricky build.
Remember _I_ am one of the ones who very much would rather not ever have
to install Perl _anywhere_. However I'm not going to question the
implementation choices of other programmers when I just want to use
their software, particularly not if I'm unwilling or unable to "put my
money where my mouth is" and provide a new "perl-free" implementation.
> However, you have not answered the question. The question I asked
> was why you want to force everyone to have Perl installed on their
> build machines just so that they can apply patches.
I have answered that question. Several times I thought. Here's another
go at it:
Because that's what _must_ be done to support packages which ship with
broken "configure" scripts. There is no other sane way to do this.
Indeed it's impossible to do if all the localization features of pkgsrc
are to be fully supported as they really should be. Currently there are
some really horrible hand-made hacks to "configure" scripts hiding in
the depths of pkgsrc, often without even accompanying "functionally
similar" patches to their source! These hacks are unacceptable.
Of course if you would rather just mark them "broken" and de-support
them until they are fixed by their author/maintainer then please be my
Besiges, "everyone" does not need to have perl installed on their build
machines. Only those people who choose, of their own accord, to build
from source any package that ships with a broken "configure" script.
Lucky for them the whole process is automated and they don't need to
know when this is necessary. They only need to type "make install" once
(and maybe they need to type the root password a few extra times if like
me they do builds as a non-root user....)
Note also that this isn't about applying patches per se, but only about
fixing distribution bugs in the GNU Auto* generated configuration
programs and makefiles used to configure and build some few packages.
If you really want to install something that pkgsrc has declared needs
autoreconf'ing but you don't want to do that, then there's always a
manual build and install in /usr/local or whatever. This isn't about
"forcing" anyone to do anything. There are lots of choices -- some
harder than others, but choice none the less.
I don't even _need_ autoconf and the configure script it generates in
order to build some piece of software that normally uses it. However
I'm sensible and sane enough to accept that my time is not unlimited and
that such conveniences are well worth the trouble they cause. I only
need to install Perl once to autoreconf and automake every package. The
cost of waiting for perl to compile even on an SS2 or an old i486sx25 is
soon paid off in the savings to my time from a bulk package management
I will note that sometimes patches are made to configure.in files that
are only necessary for one or a very few architectures, or (IIRC)
sometimes even only for a non-NetBSD platform. In those cases it would
be "nice" if the pkgsrc Makefile was smart enough not to autoreconf the
package when it's not necessary......
Greg A. Woods
+1 416 218-0098; <firstname.lastname@example.org>; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>