Am Freitag, den 12.08.2005, 02:12 -0700 schrieb Steve Langasek: > On Fri, Aug 12, 2005 at 10:15:41AM +0200, Bas Wijnen wrote: > > I have some packages which use autotools. I thought it would be good to > > compile as much as possible, so it is clear all the sources are correct. > > That > > means including autoconf, of course. > > > However, linda doesn't agree with that: > > W: gfpoken; Package Build-Depends on automake* or autoconf. > > This package Build-Depends on automake* or autoconf. This is almost > > never a good idea, as the package should run autoconf or automake on > > the source tree before the source package is built. > > > lintian doesn't consider this to be a problem. > > > My question is: is linda correct and should I not run autoconf from > > rules.make? Extrapolating that would mean that compilation is not needed at > > all, if a precompiled version of the program is packaged in the source > > tarball. That doesn't seem right to me. So if linda is right, then where > > is > > the limit? Generated files which are included for portability reasons > > (such as > > configure) are ok, but others are not? > > The limit is between autogenerated sources that upstream ships in the > tarball, and autogenerated sources that are expected to be built at build > time. > > If you rerun autoconf/automake/libtool at package build-time, when you don't > need to, what you get are large diffs against upstream every time a new > version of the autotools becomes available.
The advantage: If the autotools package maintainers do a good job (and I believe they do), you will always have up-to-date and working autotools stuff/macros/scripts in the package. The disadvantage: It surely increases the diff's size. > Aside from wasting (a little) > space in the archive, that makes it harder for NMUers or passing developers > to see what's going on in your package. In this case, you could use dpatch to change things and then it is not harder to see, what is going on. > The autotools-dev README.Debian is a good guide to these issues. But it does not recommend a special way. It also explicitly mentions the way, the OP asks for. - just my 2 cents - Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
