Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Sun, Feb 17, 2008, Russ Allbery wrote:
> > I think we should recommend (but not require) that AM_MAINTAINER_MODE
> > not be used, and perhaps work to specify an optional debian/rules target
> > that regenerates the build system in an appropriate way. That seems to
> > provide the necessary benefits for users who need to change these files
> > without imposing an unacceptable burden on developers. I don't think
> > there's a good cause to go much further than that at this point.
> I think this would in some respects be the worst of both worlds. The
> problem with not using AM_MAINTAINER_MODE is that the autotools *may* be
> run but generally aren't. This means that build dependencies only needed
> when one modifies those files aren't present or aren't tested. Modifying
> one of those files can suddenly spark the discovery that upstream isn't
> compatible with the current autotools, the partial run of Automake can
> leave the whole tree in a broken state, and so forth.
> But I suppose that's basically the normal argument for AM_MAINTAINER_MODE.
Yes, I second Russ here and would like to add that it's very easy to
trigger the timestamp skews if you simply create a patch for
configure + configure.in/.ac as the files will be sorted as configure
first and then configure.in/.ac so that applying the patch causes
configure.in/.ac to be newer than configure...
Also, automake/autoconf/aclocal might be triggerred while e.g. some m4
macros aren't installed on the buildd or the developer's system. Of
course these are usually shipped with the upstream tarballs, but are