Re: automatic autoconf config file updating
+++ Russ Allbery [2014-04-16 11:42 -0700]:
> Wookey <wookey@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.
Yes, I should have qualified my message to say 'this is only
considering the easy, config-update part of this'.
I too am in favour of full autoreconfing, for the reasons you covered.
The one thing to say in favour of just the config.{sub,guess} part (I
wish it had a better 'name' :-) is that it is something so safe and
simple that it could just be done, without every maintainer having to
do an upload. Breakage would be negligible and a large fraction of the
problem would be solved (for arm64 and many other ports, although not
for the ppc64el port or cases like it), and it could be done in a
week or two, not a year or five. Gating on an upload with debhelper
compat level change, and for some packages actual work by maintainers
to fix 'newer autotools' breakage is going to make this a slow
transition.
Still, we do like to do things properly if slowly round here, so I'm
quite happy that the consensus seems to be to solve the hard problem
and not just part of it.
I explore a bit below whether it makes sense to work on both of these
things.
> 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.
Agreed
> 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).
Does CDBS have 'compat levels'? Maybe it doesn't matter as the
debhelper one will show through in this case?
Also this doesn't fix things for packages using autoconf but not
debhelper (whether via CDBS or not). I guess those can/should only be
fixed by explicit changes to the rules file (to run dh_autoreconf) or
an autoconf patch which would update the config files by default.
Ben, are you following this thread? If you don't object violently to
adding Paul's 'update from Debian canonical config.{sub.guess}
locations by default' patch to the Debian autoconf, then that just
leaves my original issue of what ensures that those files are
installed at build time? Can we put it in Build-essential, or do we
have to have every package build-dep on it explicitly (which get us
back to the 'fix every package' issue (although it is a trivial fix
that anyone can get right in this case)).
Some input from the debhelper and CDBS maintainers on whether they
think Russ's approach makes sense would be good.
> 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.
What is the right build-dependency for non-debhelper packages?
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: