This one time, at band camp, Manoj Srivastava said: > Hi, > > > In all of the following discussion, no one has ever said > anything about *WHY* policy states that clean must undo what build > does. Unless we are clear on the rationale for dictum, trying to > resolve the issue is like playing blind man's bluff. > > There are several reasons for wanting a clean target: > a) one should be able to iteratively tweak the source code, and so > the build/clean cycle should be idempotent. > b) The build process must be reproducible -- and this is where I see > the aautotools recommendation failing. If we are supposed to be a > part of the free software community, we expect suers to contribute > back to us. One of the major areas where such help is needed is > debugging -- so someone building in a non-buildd or a non-one-shot > build process , should have the same, reproducible results as the > developer does. Fully agreed for both. > On Sat, 11 Nov 2006 13:52:06 +0000, Stephen Gran <sgran@debian.org> said: > > > It would be nice if we could support all sorts of forms of rebuilds, > > but in practice, what we tend to take seriously is the sort of FTBFS > > bugs that will affect the autobuilders. Since they build from an > > intermediate form generated by Debian developers (debian/rules), I > > am not sure how much we should worry about other use cases. > > I think we should worry a lot about other sue cases, or give > up the pretense that we are a free software distribution. The > buildds are just delivering a binary only distribution to the end > users; the free part comes from delviering source cod4e that our end > users can tweak and modify and rebuild from. > > Policy should not be just concerned with releases and > delivering binary packages, but with the overall goals of the > distribution as a free software project. I think I haven't made myself clear, if you're reading that from what I wrote. What I mean is, we frequently see "I'm rebuilding the archive, and your package FTBFS", and we all say fine, no problem, let's fix the bug. If someone comes along and say "I'm reautotooling the entire archive, and your package FTBFS", I might be inclined to ask why they wanted to do something like that. The autotools have been until recently fairly fragile. Macros that worked with autoconf2.13 don't work with autoconf2.5x and vice versa. Unless you constantly rework the .am and .ac files to keep pace with upstream autotools changes, then occasional breakage isn't so much a bug as expected behavior. I'm not arguing for being opaque, or eliding real problems in favor of a fast release. I am just mentioning in passing that redoing your build system on the fly mid-build can be expected to have a few hiccups. We frown on autogenerated debian/control's for similar reasons, right? -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature