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: > > > 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. Yes, that's a good point. For such cases, I don't mind if the package would keep the bug for having an improper clean target open and/or tagged upstream, because it is hard to fix. > > > 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... C isn't really that stable. When we upgrade the default gcc version, there're always some packages that break. Of course they break on not being proper C, but still, the problems exist. I think there are less problems with new autoconf versions, but I didn't check that. > > 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. 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. ;-) As an example, I needed 3 extra lines and a Build-Depends for gnujump: export ACLOCAL=aclocal-1.9 -I /usr/share/autoconf-archive export AUTOMAKE=automake-1.9 autoreconf -f -i -s (The last line in the build target.) When I wrote that, I didn't know automake-1.10 was out (if it was...) Otherwise I would have used that and tested with it. > 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. Yes, I'm regularly using debian/rules as documentation as well. I don't usually want to check autotools stuff, but it would sure be nice if I could. For example, I think it is very useful in gnujump that debian/rules (and control) shows that autoconf-archive is needed, and how it is used, to run aclocal. > > > 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. No, I don't want to force a version, I want the package to force it. That is, if a package requires automake-1.4, it should ask for that. Build-depending on "automake" is dangerous, because with a new automake release it's not at all unlikely that you have given yourself an FTBFS bug. > If you're keen on introducing this I'd suggest doing some work to see > how much effort would be involved in doing so. I'm happy to do so, but don't really see where I could start. I would probably want to regenerate the autotools files for packages which currently depend on autotools-dev. However, I think there isn't really a standard way for that. That's the reason I want it in debian/rules. :-) Or do you mean I should manually transition some packages? I'm happy to try some which are likely hard. If anyone has a package which is a good candidate (and preferably, which they don't mind running autotools at build time, so my work is actually used), please let me know. All my own packages already run autotools (when they use them). :-) > > 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. 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. > > 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. 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. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
Attachment:
signature.asc
Description: Digital signature