Re: About a mass bug report not based on Sid or Jessie.
Wookey <wookey@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: