[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: automake/autoconf in build-dependencies

On Thu, Mar 10, 2005 at 01:52:45PM +0100, martin f krafft wrote:
> I have often tried to argue my position on automake/autoconf in
> packages' build dependencies: I do not think they belong there. If
> a package does not build without automake or autoconf, it is broken
> and should be fixed. However, bugs like #298336 seem to suggest that
> other maintainers deem it entirely appropriate to "go the easy way"
> -- if I may call it that without being condescending towards Uwe.

> I seem to recall the devel-reference or some similar document to
> specifically address this issue, but I cannot find the location
> anymore.

I think you're thinking of /usr/share/doc/autotools-dev/README.Debian.gz

> Thus I am interested in opinions of people who argue that
> automake/autoconf are perfectly acceptable as build dependencies.
> Also, are there technical arguments against these build
> dependencies? I am too inexperienced with the GNU autotools to
> come up with something.

The arguments _for_ build-depending on the various autotools are (off
the top of my head)

(In the below, read autoconf as autoconf/automake. ^_^)

* keeps .diff.gz small and readable, as configure changes are
  not included. And small configure.in changes cascade into many
  configure changes
  * This is a maintainer decision, really. Not _wrong_ per se.

* timestamp skew means that the autobuilt makefiles will try
  to rebuild configure from configure.in even if configure is patched by
  dpkg-source at the same time as configure.in
  * A solution for this is in the above-mentioned README.Debian

* Upstream distributes without generated files (eg. CVS pull)
  or with generated files using older or buggier versions of the
  * In this case, pristine source tarball means pre-autoconf,
	and the maintainer again wants to keep the .diff.gz small.

> I am perfectly aware that there are (and should be) exceptions. For
> instance, if a package should be made available sooner rather than
> later, and the maintainer then sits down to work on the autotools
> configuration to fix the bug for the next upload. However, this
> always bears the danger that the maintainer then loses interest and
> the archive will contain what I claim to be a broken source
> package... even though it may well build.

I'm not sure I'd consider a package that build-depends on autoconf to be
_broken_ per se. I don't _believe_ this shows up anywhere in policy or
otherwise that can make this a non-ignorable bug report for such a
package. I welcome corrections on this point. I am particularly
interested in an argument that spells out how this is broken, as opposed
to "not neat in my opinion".

I _do_ think it is a riskier way of dealing with a package, as I'm not
sure what new features are expected to appear in autoconf that weren't
in the version used at last build-time, that can be taken advantage of
automatically. Surely a bugfix in autoconf would have either already
caused a bugreport against the package, or have been irrelevant to the
package itself?

Certainly, this dubious benefit to my mind does not outweigh the risk of
having a previously working build-environment suddenly break, as I
vaugely recall happened when autoconf went from 2.13 to 2.53 and
suddenly half of the Debian archive FTBFS. (Exaggeration used for
effect. ^_^)

I don't see how build-depending on autoconf etc could possibly speed up
a package release, unless the maintainer is trying to move to a
different autoconf version than upstream is using, and refuses to
install the version upstream is using. (But is happy for the buildds to
do so)

In short, _I_ wouldn't do it, same as I wouldn't build-depend on flex
and bison. I might not store their output in my CVS tree, but I wouldn't
build-depend on them either. (And if anyone feels the need to ask me
what this means in terms of 'What is source?' they get to stand between
me and Andrew Suffield if I answer. ^_^)

(This doesn't apply to config.sub and config.guess. I _do_ pull those at
build-time, since _they_ sometimes need to be upgraded for different
architectures. This is a different (controversial?) issue. ^_^)

Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.

Attachment: signature.asc
Description: Digital signature

Reply to: