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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]