Re: About a mass bug report not based on Sid or Jessie.
+++ Russ Allbery [2014-04-18 11:43 -0700]:
> Wookey <wookey@wookware.org> writes:
>
> > 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.
OK. That helps. This seems a tad perverse given that configure needs
uptodate config.* files whether or not automake is used to make
makefiles. But I guess there is some logic behind it.
> 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.
Which is fine, and a solution I'm happy with; although people were
arguing earlier in this thread that the right way to do this was
upstream, and not with special debian-foo. This doesn't meet that
criterion, although I don't see how we can without diverging from
upstream behaviour.
> 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.
It may be that libgc upstream's autogen.sh script is not really 'right' in
some way. But there may well be a lot of upstreams like that, which is
why maintainers need clear guidance on how to deal with this, without
having to become autotools experts. i.e how to determine when they can
just run dh_autoreconf and when they need to do something more
involved.
The script basically does:
aclocal$am_version
autoconf
autoheader
automake$am_version -ac
libtoolize --automake --force
is that equivalent to dh_autoreconf?
> > 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).
OK, sounds sensible to me. Joey?
> > 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.
That's fine in theory, but in order to convert from what your package
currently does to this new way you need to know enough to understand
if your autofoo is set up right, and that any package-specific macros
or configure snippets or whatever end up in the right places.
> > 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*.
OK, but again maintainers needs enough info to judge whether there is
something important in upstream's autogen.sh or if it's all effectively
boilerplate that a straighforward autoreconf will replace.
> > 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.
Good, we appear to be in agreement :-)
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: