Re: About a mass bug report not based on Sid or Jessie.
Wookey <wookey@wookware.org> writes:
> 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).
Automake is the component that's responsible for doing this. Packages
that use Autoconf but not Automake will require explicit updating of those
files. There may be more of those than I expected. If so, I think the
solution would be to add the autotools-dev logic to dh-autoreconf as well
so that it will do the updates for packages where autoreconf doesn't do
the job.
I'm not sure what's going on with libgc and haven't looked at it. It's
possible that something complexity is hiding the relevant Autoconf macro
from Automake so it doesn't realize it's in use and doesn't update those
files.
> 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?
Well, I guess I can say this: if you have a typical Autoconf, Automake,
and Libtool package, dh-autoreconf will do the right thing. I have a
bunch of those, both ones for which I'm upstream and ones where I'm not,
and have never had any trouble.
If you're doing unusual things, or if you're not using Automake, you're
right that currently dh_autotools-dev_updateconfig is more reliable. I
think that logic should be added to dh-autoreconf so that we can focus on
a single tool that's comprehensive (whether directly or via a dependency).
> 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.
I don't think maintainers should have to understand anything other than
"stick this rune in debian/rules." We should make the tools smarter, not
the packaging.
> 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?)
automake is the relevant command. In general, though, I would be very
dubious of using the upstream autogen.sh file alone. If it regenerates
other things as well that one wants to regenerate during the packaging,
that's great, but in general I'd still let dh-autoreconf run autoreconf
itself, unless that actually *breaks*.
> running dh_autoreconf (or dh --with autoreconf) doesn't do anything
> different with respect to config.* file updating than autoreconf?
I believe that's currently correct, and I think you've identified good
reasons for changing that.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: