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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Mon, Feb 11, 2008 at 10:53:48AM +0100, Bas Wijnen wrote: This is not true if you simply build the whole package from source. That is, run autotools during build, remove all generated files, including Makefile.in, configure, etc, in the clean target. For some reason many people seem to think that the whole package must be built from source, except for configure and Makefile.in. I still don't understand what the idea behind this exception is. Especially when it leads to unwanted concequences (unreadable diff.gzs, for example), I don't think it is a good idea to hold on to the idea that running autotools is not part of building the package. It's a well-established principle of the GNU build system that there are targets that are run by maintainers and there are targets to be run by people building the package. This division is there to make our lives easier, and ignoring it, IMHO, is cutting off our nose to spite our face. (Even the section in the GNU Coding Standards regarding the maintainer-clean target doesn't go so far as deleting configure.) The underlying problem here is that users who change configure.ac etc. need to do some additional manual work to update the build system, and that this should be done automatically. I agree. However, this is not the same as regenerating the full build system from scratch on every build. You should be aware, if you aren't already, that the process of generating a package's build system from scratch is often really quite complicated and may well involve network access, which build daemons do not have. For example, the usual update process for a package that uses Gnulib involves rsyncing translations for some messages from translationproject.org. If you mandate that Debian maintainers must support full build system regeneration on every build, then you will force some of them to maintain a separate bootstrapping process which is guaranteed not to access the network, which will involve duplicating work already done by upstream and will undoubtedly introduce errors at some point. Mere incremental regeneration on demand is much simpler and is often already supported by upstream build systems without requiring any change (see below). I suggest to mandate remove all generated files in the clean target (formulated in a way which includes generated by upstream, not only generated by the build target), which implies rebuild everything in the build target. I object to this proposal. As an example, I am upstream for man-db and know that its build system is properly generated. Requiring that I regenerate it every time I build the package would introduce nothing but hassle for me, and would not in practice provide significant benefits for users since the build system already caters for them out of the box (see below). With the current wording it is allowed to use shipped built files from the upstream tarball, as long as the source is present. It is even allowed to ship the build results (uuencoded, for example) in the diff.gz and use those. I suppose we all agree that this is unacceptable for normal build results. configure is readable, if you have to. It's not the preferred form for modification, certainly, but it's not an opaque object file either, and there's no need to treat it exactly as we would treat opaque object files. Bear in mind also that, while upstream maintainers will probably accept that configure.ac files that don't work with current versions of Autoconf are bugs, they are also unlikely to have immediate sympathy for I rebuilt your package with a version of Autoconf three years newer than the one you used and it produced a horrible mess; please help me untangle it. In other words, this proposal will have the effect of requiring that Debian maintainers become experts in the Autotools before being able to upload policy-compliant packages again, whereas that burden could formerly be passed to upstream to be dealt with on their schedule. I wouldn't expect that figuring out enough about the Autotools to be able to do this should be beyond most Debian maintainers, but neither would I expect that they could all deal with some of the weird stuff I've seen already. I agree that behavioural changes due to regenerating the build system are bugs, but what you're suggesting is that all such bugs be elevated to the status of showstoppers, as it will be impossible to upload packages without it. I'm sure that that would make the security team's life a lot harder, for instance - while there are a few vulnerabilities that require configure.ac changes to fix, in most cases you can get away without needing to do so. Furthermore, if as a user you're desperate to make a small tweak to configure.ac, it *is* often quite possible - if ugly! - to just make the obvious corresponding change to configure and then get on with your life. You can't realistically do that with e.g. compiled C object files, which is one reason we treat them differently. Now
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 often missing/incomplete. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Sun, Feb 17, 2008 at 08:24:43PM +0100, Loïc Minier wrote: 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... 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. ;-) 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. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397939: Lintian: outdated-autotools-helper-file
Russ Allbery [EMAIL PROTECTED] writes: Bas Wijnen [EMAIL PROTECTED] writes: Autoconf is pretty stable, This has not been the experience of many of us. I haven't had a lot of trouble fixing things for newer releases of Autoconf, but I definitely have seen issues. And the Autoconf 2.13 to 2.50 transition and all the subsequent instability was not that long ago. Autoconf 2.50 was released in May 2001. That's almost 7 years ago now. By free software release standards, I would not consider that not that long ago. -- Ben Pfaff http://benpfaff.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Mon, Feb 11, 2008 at 10:53:48AM +0100, Bas Wijnen wrote: I suggest to mandate remove all generated files in the clean target (formulated in a way which includes generated by upstream, not only generated by the build target), which implies rebuild everything in the build target. Tell me how I, as an upstream, can use an experimental version of libtool in that situation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
