On Sun, Feb 17, 2008 at 11:55:03PM +0100, Bas Wijnen wrote: > On Sun, Feb 17, 2008 at 09:29:59PM +0000, Mark Brown wrote: > > On Sun, Feb 17, 2008 at 08:08:47PM +0100, Bas Wijnen wrote:
> > OTOH if the standard Debian build process jumps through unusual hoops > > like forcing regeneration of all the autotools files that makes it less > > useful as a guide for the things you'd actually want to do in the normal > > course of affairs. > The things are pretty separate IME. The parts which do the compile > after autotools have been run can easily be found in most cases. If > not, then the file probably wasn't readable without running autotools > either. ;-) > > If you're willing to do things by forcing a particular version in the > > general case then this sounds more like something that could be checked > > outside the standard package build process. > > No, I don't want to force a version, I want the package to force it. By forcing a version I mean doing so in the package. > > If you're keen on introducing this I'd suggest doing some work to see > > how much effort would be involved in doing so. > Or do you mean I should manually transition some packages? I'm happy to Yes, that's the sort of thing I meant. > > We already have regular tests for things that aren't caught by the > > normal build processes, this could be checked in a similar fashion. > We could check if an automake upgrade would produce many FTBFSs, if the > packages are already build-depending on automake. However, most > packages currently don't do that, and it's in the general case not > possible (AFAICS) to run it for them automatically. What I'm suggesting is that if you add something out of the normal build process which regenerates autotools stuff (like an extra target in the rules file, for example) then we could test this without doing it on every single build. > > Personally, I expect the package to restore things to the state they > > were in the distribution tarball. > That has been suggested, but it would mean backing up generated files > which get overwritten during the build (such as config.guess and > config.sub). There seems to be agreement that such backing up is not > useful. My point is that I don't expect the clean target to clean with respect to anything except the upstream tarball rather than going around making things clean with respect to upstream revision control or similar. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
