[Wouter Verhelst] > It has nothing to do with "being afraid to", but everything with "not > needing to". There's lots of things we don't _need_ to do but we do anyway, as a matter of quality of implementation. I believe that building a package from source is something we should do as well, if only to ensure that our packages do continue to build from source, using our tools. And when I say "from source", I'm using the GPL definition of source code, "the preferred form for making modificatons", which I think is a pretty useful definition in general. > Sure, you should verify that things still work if you run autoreconf > on your source tarball, but there is no real need to build autotools > output files in the build target of debian/rules if all you want to > do is verify that they build properly. The same could be said for lots of other tools: bison and flex are the obvious ones, but also yodl, docbook2x and other documentation convertors. Is it reasonable to tell maintainers that every architecture-independent generated file should be built manually and shipped in the .diff.gz rather than built as part of the debian build? > Moreover, this thread, at least to me, is more about what an upstream > should do rather than what a Debian developer should do; it is not > good practice as an upstream to assume that anyone else than yourself > will need to run the autotools on your input files on a regular > basis. What an upstream should do and what Debian should do are quite different things. It has long been accepted that an upstream's best practice is _not_ to require users to have autoconf installed locally - they can assume you have a compiler and make and common tools like awk, but not autoconf or flex. Debian does not have this problem. Our 'apt-get build-dep' command ensures that it is convenient for our users to use pretty much any tool we need, when rebuilding our packages. We don't _have_ to worry about providing pre-built output from autoconf, flex, bison and the like. Our build dependencies even make it easy to require a particular minimum version of any tool. In summary, I think it's important for our users to be able to build packages from source. This implies that _we_ should build from source, in order to exercise the whole toolchain, so that we know it always works. And if it's so fragile that it _doesn't_ always work ... well, then _that's_ a problem which needs to be addressed. Is the autoconf unreliability problem really so intractible that it requires a workaround of "don't ever use it except in a manual process where you can test it immediately to see if it worked"? Would we tolerate that same requirement in a tool like docbook2x?
Attachment:
signature.asc
Description: Digital signature