Re: About a mass bug report not based on Sid or Jessie.
+++ Russ Allbery [2014-04-17 14:24 -0700]:
> Florian Weimer <fw@deneb.enyo.de> writes:
> > * Russ Allbery:
>
> >> It's an interesting question whether we should just force dh-autoreconf
> >> in debhelper unless the package maintainer explicitly turns it off. It
> >> would save me work, just as I've now been able to take overrides back
> >> out of all of my packages now that dpkg defaults to xz compression.
> >> But it would be disruptive, and some packages would definitely fail to
> >> build afterwards.
>
> > The correct long-term fix is to change autotools to check a list of
> > well-known paths for more recent versions of the scripts and use them
> > instead of what is provided in the package.
>
> This doesn't regenerate the other files from scratch. This only addresses
> config.{sub,guess}, which is only a small part of the problem. And if you
> run autoreconf, that takes care of this update as well (at least most of
> the time).
Can someone explain how this works, because so far as I can see this
isn't true (well maybe 'most of the time' is true, but there is a
non-trivial 'rest of the time' and we need to understand when/why that
occurs, so we can make those DTRT too).
The autoconf package (containing the 'autoreconf' command) does not
have a copy of config.{sub,guess} (so cannot update them). The
autotools-dev packages does, but it puts them on debian paths that are
explicitly ignored by autotools (and thus autoreconf) unless _debian_
dh_something command is used, and even then they won't necessarily be
picked up (see my post about the libgc example where dh_autoreconf did
not find them).
Now I see that there is a copy of config.{sub,guess} in automake (in
/usr/share/automake-1.14/) so I guess that if automake is also used
(or maybe just installed?) then modern versions of these files will be
found and used (always?, sometimes? - what are the rules? libgc uses
automake and they did not get found).
> I therefore don't think pursuing this is particularly useful,
> and we should instead make this problem moot by using dh-autoreconf or
> something similar.
I agree with the sentiment, but I don't understand how this is going
to work, because we know that using dh-autoreconf does not always
result in updated config.{sub,guess}. If changing the search paths is
not the right fix then what is? Making dh-autoreconf explicitly
install and run dh_autotools-dev_updateconfig would work, except where
it is overridden by an autogen.sh script. Is that effectively what is
being proposed?
And who understands all this well enough to explain to maintainers
what they should be doing, because if I don't really understand the
gubbins after way too much porting and crossing and bootstrapping
faffage, I assume the average packager is even less clear about all
this.
In summary:
autoconf does not contian config.* files
autotools-dev contains current config.* files (on debian path)
automake contains current config.* files
autoconf does not depend on autotools-dev or automake
autoconf package supplies autoreconf command
autotools-dev package supplies dh_autotools-dev_updateconfig (and restoreconfig) commands
dh-autoreconf packages supplies dh_autoreconf (and clean) commands
running dh_autotools-dev_updateconfig (or dh --with autotools-dev)
will always copy debian config.* files into package
This is where I start to get vague:
running autoreconf will only copy (use-without-moving(?))
config.* files if automake is installed(?) used(?) _and_ an autogen.sh
file is not used/has specific commands (which ones?)
running dh_autoreconf (or dh --with autoreconf) doesn't do anything
different with respect to config.* file updating than autoreconf?
Please correct any misunderstandings I have.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: