On Mon, Feb 11, 2008 at 09:21:29AM -0800, Russ Allbery wrote: > Bas Wijnen <shevek@fmf.nl> writes: > > > I suggest to mandate "remove all generated files in the clean target" > > (formulated in a way which includes "generated by upstream", not only > > "generated by the build target), which implies "rebuild everything in > > the build target". > > [...] > > > I'd like to hear why this exception is so important for people. Or > > better yet, I'd like to hear that everyone agrees with me, so we can > > make this change and finally to the Right Thing. :-) > > It may be less common now, but for many years it was quite common for > upstreams to use very specific versions of autotools, which means that if > Debian had dropped the specific autoconf in question, it wasn't easy to > regenerate the files. Now, that may be a problem for other reasons since > as you point out it means we don't really have horribly usable source, but > that's the most common practical concern, I think. Oh, I didn't know that. IMO that would mean the package should really be in contrib, because we're missing a build dependency in main then (not used, but AFAIK using pre-built files is not an acceptable way to avoid getting in contrib in such a situation). Anyway, I don't think that is still a reason for not running autotools nowadays, so it's just historical background. :-) > Always re-running autoconf and automake would increase the number of > FTBFS's that we'd need to fix. Not really. It would lead to many bugs that packages aren't following policy. Especially if we start with should and later (possibly) upgrade it to must, I think it is workable. In particular because these bugs don't actually stop a package from being built. I would be very happy with consensus that the autotools _should_ be run during build. The implementation of actually doing it in all packages may take a while, I don't have a problem with that. Unless of course you are talking about cdbs. When that changes to running autotools, it likely needs to know if there are extra arguments. That may indeed result in FTBFSs for many packages which use it (because they may need, but don't provide, the arguments). But it's good when they're fixed as well. :-) > (Probably for the greater good of free software, but.) Yes, IMO it's one of those situations where Debian should do what's Right, not what's Easy (similar to what I wrote about the /bin/sh bash->dash move on -policy today). > Also, it's not always easy to figure out which files are generated in > order to remove them, but that's probably programmatically fixable. That's in principle a problem for the maintainer to solve, and secundarily for lintian. If things can be automated, that may be nice, but it is not required. Once policy mandates to remove generated files in the clean target, it's up to the maintainer to do it. And if the maintainer makes a mistake and forgets to remove a file, that's not a big problem (it would be a bug with this change in policy, but only a minor one, IMO). At this moment however, I don't think there is consensus yet that it is always better to remove all generated files, including autotools-generated stuff, in the clean target. After that happens, we can think about how to implement it in the archive. Slowly, I would suggest. :-) Because it is a good thing if we do this Right, but we shouldn't break half the archive for it. ;-) 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