Gergely, On Mon, 2011-07-04 at 12:10 +0200, Gergely Nagy wrote: > Kilian Krause <kilian@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). Perfectly agreed, it's "not the best solution in all cases". > 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. Maybe it's just me knowing more upstream sources with a tendency to break randomly rather than just coping well with frequently running autoconf (and still getting the desired result). Anyway, my point was that I'm not willing to spend time on investigating a package that I would otherwise sponsor and find out the long way. It *may* be having a dead simple build system, but finding out and especially finding corner cases will demand much deeper inspection than just the patch with the updated part required. > 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. Depends on how large the change is. Usually you can strip this down quite well to only a one page diff that's really required. So I guess we can make this a personal requirement for me sponsoring a package. -- Best regards, Kilian
Attachment:
signature.asc
Description: This is a digitally signed message part