On Fri, Aug 12, 2005 at 12:04:31PM +0200, Bas Wijnen wrote: > On Fri, Aug 12, 2005 at 02:12:57AM -0700, Steve Langasek wrote: > > 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. > That sounds like a good way to sneak non-free stuff into main. In fact, > gfpoken is a good example of that. The new upload doesn't use the original > artwork, because it had to be compiled with povray. However, the compiled > files were in the source tarball (in fact, the art source was in a different > tarball). Opinions vary wether it was needed to have art with a free > compiler, but that's because it's about art. If it would have been a piece of > C code, generated with a non-free compiler, then the package obviously > shouldn't be in main. However, if upstream (which could be the packager) has > pregenerated the files, then according to this rule there is no problem. That > doesn't seem right. Well, yes, you do need to know your packages, and take appropriate care that they meet the DFSG. But that doesn't mean having large auto-generated diffs against your upstream release is a good idea. In the case of upstream tarballs that contain binary object files that they shouldn't, at least, the usual practice is to remove them and re-roll the tarball. > > 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. 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. > I noticed that, and "manually" removed all files generated by auto* in > debian/rules:clean. That way they get ignored for the diff. Hmm, I'm not really sure whether that fits with policy's intent regarding the effects of the debian/clean target. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature