On Thu, Mar 10, 2005 at 01:52:45PM +0100, martin f krafft wrote: > I have often tried to argue my position on automake/autoconf in > packages' build dependencies: I do not think they belong there. If > a package does not build without automake or autoconf, it is broken > and should be fixed. However, bugs like #298336 seem to suggest that > other maintainers deem it entirely appropriate to "go the easy way" > -- if I may call it that without being condescending towards Uwe. > I seem to recall the devel-reference or some similar document to > specifically address this issue, but I cannot find the location > anymore. I think you're thinking of /usr/share/doc/autotools-dev/README.Debian.gz > Thus I am interested in opinions of people who argue that > automake/autoconf are perfectly acceptable as build dependencies. > Also, are there technical arguments against these build > dependencies? I am too inexperienced with the GNU autotools to > come up with something. The arguments _for_ build-depending on the various autotools are (off the top of my head) (In the below, read autoconf as autoconf/automake. ^_^) * keeps .diff.gz small and readable, as configure changes are not included. And small configure.in changes cascade into many configure changes * This is a maintainer decision, really. Not _wrong_ per se. * timestamp skew means that the autobuilt makefiles will try to rebuild configure from configure.in even if configure is patched by dpkg-source at the same time as configure.in * A solution for this is in the above-mentioned README.Debian * Upstream distributes without generated files (eg. CVS pull) or with generated files using older or buggier versions of the autotools. * In this case, pristine source tarball means pre-autoconf, and the maintainer again wants to keep the .diff.gz small. > I am perfectly aware that there are (and should be) exceptions. For > instance, if a package should be made available sooner rather than > later, and the maintainer then sits down to work on the autotools > configuration to fix the bug for the next upload. However, this > always bears the danger that the maintainer then loses interest and > the archive will contain what I claim to be a broken source > package... even though it may well build. I'm not sure I'd consider a package that build-depends on autoconf to be _broken_ per se. I don't _believe_ this shows up anywhere in policy or otherwise that can make this a non-ignorable bug report for such a package. I welcome corrections on this point. I am particularly interested in an argument that spells out how this is broken, as opposed to "not neat in my opinion". I _do_ think it is a riskier way of dealing with a package, as I'm not sure what new features are expected to appear in autoconf that weren't in the version used at last build-time, that can be taken advantage of automatically. Surely a bugfix in autoconf would have either already caused a bugreport against the package, or have been irrelevant to the package itself? Certainly, this dubious benefit to my mind does not outweigh the risk of having a previously working build-environment suddenly break, as I vaugely recall happened when autoconf went from 2.13 to 2.53 and suddenly half of the Debian archive FTBFS. (Exaggeration used for effect. ^_^) I don't see how build-depending on autoconf etc could possibly speed up a package release, unless the maintainer is trying to move to a different autoconf version than upstream is using, and refuses to install the version upstream is using. (But is happy for the buildds to do so) In short, _I_ wouldn't do it, same as I wouldn't build-depend on flex and bison. I might not store their output in my CVS tree, but I wouldn't build-depend on them either. (And if anyone feels the need to ask me what this means in terms of 'What is source?' they get to stand between me and Andrew Suffield if I answer. ^_^) (This doesn't apply to config.sub and config.guess. I _do_ pull those at build-time, since _they_ sometimes need to be upgraded for different architectures. This is a different (controversial?) issue. ^_^) -- ----------------------------------------------------------- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Anu.edu.au "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. -----------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature