+++ Russ Allbery [2014-04-18 11:43 -0700]: > Wookey <woo...@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/ -- 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/20140418222018.gr29...@stoneboat.aleph1.co.uk