On Sun, Feb 17, 2008 at 08:08:47PM +0100, Bas Wijnen wrote: > The fact that there exist packages which work properly without > recompiling from source doesn't mean it's a good default. IMO the > default should be to always compile from source. Yes, that means hassle > for the packager; it's pretty much the whole task of packaging.
It's probably worth bearing in mind that there are quite a few people out there who use autotools for want of a standard alternative and are either indifferent to it or actively dislike it. Often people have been burned by the version incompatbilities in the past and try to avoid having anything to do with it - I've seen people do things like check the generated files into their VCS to avoid dealing with the churn. I'm not sure how prevalent this is it is an issue. > > In other words, this proposal will have the effect of requiring that > > Debian maintainers become experts in the Autotools before being able > > to upload policy-compliant packages again, > Not at all. Autoconf is pretty stable, so I suppose you're talking Not as stable as, say, C by a long way... > then IMO it's totally reasonable that that weirdness is in debian/rules, > so users can see what's happening, if they want to. 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. I know I've found Debian packages very useful for that when doing things like working on programs for upstream purposes or for non-Debian things like cross development. > > I'm sure that that would make the security team's life a lot harder, > > for instance > Perhaps you mean that lots of bugs pop up when "automake" increases its > version? In that case I apologize for being unclear; I thought it was > commonly known and agreed upon that you should always build-depend on > the versioned package. 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. If you're keen on introducing this I'd suggest doing some work to see how much effort would be involved in doing so. > Not at all. If it's optional, it's likely that many packages will not > have it. Also, if the build system doesn't use it by default, it is > likely that many of those targets are never tested and don't actually > work. We already have regular tests for things that aren't caught by the normal build processes, this could be checked in a similar fashion. > Also, considering the bug we're writing to, what would you propose that > the clean target should do? "Remove all generated files, except the > ones that are generated by autotools"? I can't properly express how > completely wrong I find such an exception when written in Policy... Personally, I expect the package to restore things to the state they were in the distribution tarball. -- "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]
