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

Re: automake/autoconf in build-dependencies

Paul.Hampson@anu.edu.au (Paul Hampson) writes:

> 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

Once more autobuilders switch to 2.6 kernels this will happen even
more often. Till now a lot of buggy sources just got lucky during

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

Personaly I prefer the autotools-dev solution with proper timestamp
fixes in debian/rules. That means that the package will be build with
the same scripts on all hosts except for config.{guess,sub}. That is
most likely to succeed.

Second place is sources with a Build-Depend on automake/autoconf and
no generated files in the source. That avoids timestamp skews even
when a buildd is a few timezones in the past compared to the upload.

Anything else fails randomly.


Reply to: