Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Sun, Feb 17, 2008, Colin Watson wrote:
> This isn't true if you just let the patch be applied by dpkg-source -x,
> since the timestamp-handling bug I mentioned earlier was fixed. It might
> be true if you use a less capable patching system. ;-)
Eh you and me know I was referring to dpatch, simple patchsys, and
quilt which suffer from this AFAIK. :)
I guess we could fix the patch systems to be as capable indeed.
> > 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
> > often missing/incomplete.
> If that is the case then the end user is going to lose out anyway when
> trying to modify the package. I'm not arguing that such bugs shouldn't
> be fixed, merely that it's a mistake to turn them into showstoppers that
> could potentially block more urgent upload requirements.
Yes, which is a common problem which reinforces your point about the
autotools suite failing to run commonly and that we shouldn't care as
urgently about.
To sum up, I'm with you on not making autotools breakage as important
as a FTBFS, but not on the AM_MAINTAINER_MODE bits: not using
AM_MAINTAINER_MODE exposes us to the fragility of autotools again (be
it because of timestamp skews, upstream mistakes, or new upstream
incompatibilities).
I was just bitten by such an issue this morning again where upstream
seems to have shipped old intltool-* files but no intltool.m4 macros,
and the automatic aclocal run by the build wasn't triggering an
intltoolize. This might have been triggerred with timestamp skews, but
wouldn't have happened with AM_MAINTAINER_MODE in place (or would
upstream have made their build run intloolize on aclocal).
--
Loïc Minier
Reply to: