On Tue, Mar 15, 2011 at 10:29:57PM +0000, Marcin Owsiany wrote: > * maintain a whitelist of distributed files, and "rm" everything > else (apart from the debian directory) in the clean target. > > Since I use (or plan to use) git-buildpackage, I don't have a tarball > which could serve as an authoritative whitelist. Thus an additional > whitelist refresh step would be required every time I merge the > upstream branch into the debian branch. That's bad. Furthermore, a > whitelist approach would mercilessly elliminate all files on a > "clean", so one would have to be really careful not to leave > unchecked but precious files in the source tree at any time... :-/
while i've heard that the latest dh/cdbs can do this automatically for you, in a few packages that I maintain where they're still running dh 5, i keep an AUTOFOO_CRUFT variable in debian rules, and have a small amount of code in the corresponding build and clean areas to "preserve" and "unpreserve" these files. Example: http://git.debian.org/?p=pkg-xorg/app/compiz.git;a=blob;f=debian/rules;h=530ff40f4e5228a6207d9d6d5a0f8a68acecc0b9;hb=a481aecfeea68adea9d0579059c8eb3a746fcd44 it's not perfect, but seems to do the trick. note that this is not a list of "everythign autofoo creates/modifies", but rather a list of "everythign that make distclean fails to remove/restore". It tends to gather files over time and some of them might no longer apply in later upstream releases, though there's no harm done apart from maybe a couple wasted cp operations. On Tue, Mar 15, 2011 at 10:55:54PM +0000, Neil Williams wrote: > Other tools, like svn-buildpackage, don't have this problem, via the > mergeWithUpstream support and/or a ../tarballs/ directory. Not perfect > but it works. no, they do have this problem but most people just choose to ignore it until it causes an FTBFS. If you build with mergeWithUpstream there is the same likelihood that cruft gets left around, it just doesn't dirty your working directory/checkout. You can still run into problems if someone downloads the source package from a mirror and tries to a build/clean/build. > I think CMake makes a better job of native packages which need > autotools-type hand-holding, so I may port to that instead. IIRC CMake for the most part generates its cruft in a nukable subdirectory, which makes cleanup significantly simpler. > Building direct from VCS is a nice idea but sometimes, it just isn't > worth the pain - let the build system build the tarball and package > from the tarball. It's just easier. Or just change the build system > and/or the tool. IYHO anyway -- I and I'm sure others would probably beg to differ :) sean -- 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/20110316085426.ga12...@cobija.connexer.com
