Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > Or do you mean that you have files in your git branch which are removed > by debian/rules clean ? (I'm no longer ruling anything out merely on > the grounds that it would be utterly insane...)
This is common. Usually it's because upstream ships generated files in the upstream tarball as well as source files. As part of building the Debian package from source, one wants to remove all generated files and recreate them. Deleting those files in debian/rules clean is an obvious way to go about this. Munging the upstream source to remove all the generated files means diverging from the upstream source tarball and losing verifiability, etc. See xfonts-jmk for a complex example. See shibboleth-sp2 for a package that has one generated file also included in the package which is changed as part of the build process. I don't want to keep carrying a diff for that file, so I remove it in debian/rules clean. This means that debian/rules clean doesn't restore the source to exactly the same state as an unpack, but it's in *functionally* the same state since that file will be regenerated as part of a build and no useful information has been lost. Saving all the build products and restoring them on debian/rules clean is more trouble than I have any interest in doing, although patches are welcome, I suppose. There used to be far more of these, but dh-autoreconf goes to the effort of stashing the files and restoring them on debian/rules clean, since someone did the effort of centralizing that support in one place. But it's a lot of work to expect individual maintainers to do for one-off cases. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pps7jocj....@windlord.stanford.edu
