On Sun, Feb 10, 2008 at 03:48:20PM -0800, Russ Allbery wrote: > Raphael Geissert <atomo64+debian@gmail.com> writes: > > > Quoting the Debian Policy, section 4.9 Main building script: > > debian/rules[1] > > > >> clean > >> > >> This must undo any effects that the build and binary targets may > >> have had, except that it should leave alone any output files > >> created in the parent directory by a run of a binary target. > > > > So according to the policy the clean target must put the original > > files back on place. > > This Policy dictate as written is pretty widely ignored and (IMO) is > somewhat hard to defend in several of its implications. We haven't > figured out what to say instead, but deleting the files is fairly > common right now. > > See http://bugs.debian.org/397939 for some additional discussion. Thank you for this link. I would like to add a suggestion as a solution. IMO the important thing is, as stated by Bill, that "clean" and "clean; binary; clean" should result in the same tree. From the log it seems that people agree that this implies either creating a huge diff.gz, or running autotools in the clean target. This is not true if you simply build the whole package from source. That is, run autotools during build, remove all generated files, including Makefile.in, configure, etc, in the clean target. For some reason many people seem to think that the whole package must be built from source, except for configure and Makefile.in. I still don't understand what the idea behind this exception is. Especially when it leads to unwanted concequences (unreadable diff.gzs, for example), I don't think it is a good idea to hold on to the idea that running autotools is not part of building the package. Apart from that, this discussion is about users making changes to the source and compiling a package with those changes in it. When not running autotools during build, that doesn't work if the user changes Makefile.am or configure.ac. Yet another undesirable effect of this strange exception to "build everything from source". 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". With the current wording it is allowed to use shipped built files from the upstream tarball, as long as the source is present. It is even allowed to ship the build results (uuencoded, for example) in the diff.gz and use those. I suppose we all agree that this is unacceptable for normal build results. Now reread the previous paragraph while thinking of Makefile.in instead of "normal build results". It is common practice to do exactly that: ship and use pre-built versions, or even ship them in the diff.gz (which then gets huge). Makefile.am is only present as source-file, but it isn't used at all during the build. Any changes the user makes will not be noticed by the build system. 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. :-) 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