Wookey <woo...@wookware.org> writes:
> So, where in debian should we put responsiblity for updating
> config.{sub,guess}?
I lean towards being more aggressive than this and running autoreconf or
the moral equivalent on any package using Autoconf, by default. For that
idea, I offer the following defense:
* Just updating config.guess and config.sub isn't sufficient in some
cases. For example, the most recent new architecture also required a
libtool patch.
* Autoconf has bugs. Refreshing automatically on build means that we can
propagate fixes to those bugs. See the recently-discovered problem with
detecting and enabling large file support.
* There is a strong theoretical argument in favor of regenerating the
build machinery from source on the grounds that we want to build things
from actual source and ensure that it's possible to modify the actual
source, as opposed to requiring people doing modifications potentially
either debug Autoconf problems or hack on opaque shell scripts.
If we assume that we want to solve the whole problem in the dh-autoreconf
approach instead of only updating config.{sub,guess}, I think it restricts
the problem space somewhat more. For example, no patch to Autoconf is
going to tackle that alone, and I think adding all of autoconf, automake,
and libtool to build-essential is a harder sell than just adding
autotools-dev.
What I'd therefore lean towards is for debhelper and CDBS (with a new
compat level) to automatically run dh-autoreconf if Autoconf was detected
but without depending on them, resulting in an immediate FTBFS on all
platforms if the package doesn't Build-Depend on dh-autoreconf but no
change for packages that use some other build system (like our innumerable
Perl modules). The maintainer will then have to add the dh-autoreconf
build dependency when they update the debhelper compat level, and then the
rest of the machinery will be taken care of by the helpers if they're
used.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d2gh2k0s....@windlord.stanford.edu
