Wookey <woo...@wookware.org> writes: > 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 took a deeper look. The problem is that --force is only passed to libtoolize, which means that the Libtool files are updated but other files are not replaced if they are present but out of date. If dh_autoreconf is run without using the upstream autogen.sh, config.guess and config.sub are correctly updated. So this is indeed a problem with using the upstream autogen.sh instead of dh_autoreconf's default action (which is autoreconf --force -i). The equivalent change to the upstream autogen.sh script is to add --force to the automake command line. > 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. True. > 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. I think what I'm arguing for is just running both. Run upstream's autogen first and then run autoreconf. Maybe that's a bad idea, though. It would be if upstream's autogen.sh is working around some bug in autoreconf and autoreconf would leave things in a broken state. Regardless, though, I will say that the autogen.sh script in libgc looks completely pointless to me in Debian and I would ignore it and just run autoreconf. The only value it's adding is probing for specific versions of the tools and aborting on 1.7 versions, which are irrelevant actions for Debian. (It's also running things in the "wrong" order, calling libtoolize last, so autoreconf may actually produce more reliable results.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- 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/87lhv2me9r....@windlord.stanford.edu