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
build.
> * 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.
MfG
Goswin
Reply to: