Re: afraid to build from source? (was Re: Remove cdrtools)
On Tue, Aug 15, 2006 at 02:42:09AM -0500, Peter Samuelson wrote:
> [Michael Poole]
> > On top of the default automake behavior being horribly broken, does
> > that make usual revision control practices horribly broken?
> It really bothers me to hear people claim as a best practice that you
> should never recompile configure.ac or Makefile.am except under
> controlled conditions. To me it is a very important philosophical
> point that Debian be self-hosting. That means packages should build
> without error from source, not just from intermediate text files like
> 'y.tab.c', 'configure', or 'Makefile.in' which, while arch-independent,
> are not particularly human-editable, and certainly not source code in
> the GPL sense.
> Using a provided 'configure' binary instead of building from source has
> the same problem as using any other provided binary rather than
> building from source. It clearly expresses a lack of confidence that
> the system _is_ in fact self-hosting. It tells our users, "we will
> give you all the source code, but you'd better not modify that one
> configure.in source file, because we do not dare trust our tools to
> build it correctly."
> So yeah, I advocate always building packages from source, and if
> autoconf someday comes up with an incompatibility that causes a FTBFS
> somewhere, let that be reported and fixed. Not just worked around by
> trying to avoid running autoconf.
It has nothing to do with "being afraid to", but everything with "not
needing to". Building and testing a C program on one architecture does
not necessarily mean that it will work on another, too. Differences that
exist in things such as endianness, word size, signedness of default
types, and other things, may mean that a C program which works perfectly
on one architecture may break on another.
The same isn't true for autoconf; this is written in portable POSIX
shell. If it works on one architecture, it works on all of them. The
output of autotools, if done with the same version, is totally
Proper use of autotools will retain that deterministic property. "Proper
use" does include things like making sure you use at least the autotools
version for which your configure.ac and/or Makefile.am was written. It
also includes making sure that you do not try to do things that will
work on one Linux-based architecture, but will fail horribly on another.
Sure, you should verify that things still work if you run autoreconf on
your source tarball, but there is no real need to build autotools output
files in the build target of debian/rules if all you want to do is
verify that they build properly.
An extra reason not to do this is that some older versions of the
autotools will not run themselves as "automake-version" or
"autoconf-version" or whatnot, resulting in behaviour that is not, in
fact, deterministic, since if you have more than one version of the
autotools installed, the default version may very well be the wrong one.
Moreover, this thread, at least to me, is more about what an upstream
should do rather than what a Debian developer should do; it is not good
practice as an upstream to assume that anyone else than yourself will
need to run the autotools on your input files on a regular basis. You
should distribute the .tar.gz (and, optionally, the .tar.bz2 if you
build that too), which you produce with 'make distcheck'. If you do
that, everything _will_ work for everyone else, and there will not be a
need to put in backwards compatibility stuff for people using older
versions of autotools.
If someone does want to modify the configure.ac or whatnot, it is not
unreasonable to ask that they upgrade to the most recent version. Of
course, you should add things like AC_PREREQ to the right input files to
make that easier, but that's a different matter.
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4