Kilian Krause <kil...@debian.org> writes: > 1. Using dh-autoreconf is ugly. Please try to avoid it and backport the > full regenerated configure in your patch to make sure the source is > identical on all buildds. IMHO dh-autoreconf is a solution for a local > build that you maintain for yourself outside of Debian, but not for an > official pacakge.
I strongly disagree with this view. While dh-autoreconf may not be the best solution in all cases, it does have its uses (apart from the obvious case where the upstream tarball does not have generated files like configure & co). For example, running dh-autoreconf instead of including the regenerated configure and whatnot in the debian.tar.gz has the following advantages: * It's much much smaller. * It makes it easy to keep the generated files up to date. Which can easily benefit the buildds. * If autoreconf breaks the package build, no big deal: it probably needed an update anyway, if for nothing else, then to allow transitioning the old version of auto* out of Debian, so we won't have 5 or more versions of, say, automake in the distribution. The only downside from my point of view, is that it pulls in quite a bit of stuff, which places some extra burden on the buildds. Of course, if a package's build system has a tendency to break randomly when autoreconf'd, then regenerating configure & co with a known good version is advisable. But for most cases, where both configure and the Makefile.ams are dead simple, I see little harm, and that's far outweighted by having a small and clean .debian.tar.gz. I believe that touching as little as possible in the upstream sources is desirable, that the debian patches remain unobtrusive and reasonably compact. Regenerating configure & co goes against this, as it touches not only the sources, but generated files aswell. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739im1hm1....@balabit.hu