Le Sat, May 04, 2013 at 03:25:34PM +0200, Lucas Nussbaum a écrit : > > Now, I'm not so sure that we should spend developer time to (1) find > those issues and file bugs; (2) fix those issues. I personally find it > easier to create a temporary git repository and to use git clean / git > checkout to return to a pristine environment.
I totally agree. Time has passed since the last large-scale control for double-buildability. In the meantime, I used Git increasingly, and now I exclusively rely on it for cleaning the source packages that I maintain. I think that it is the best technical solution, as it saves me from writing fragile makefile instructions or carrying patches that Upstream is not always intersted in. If shortcomings of the "clean" target become release-critical, I will simply start to build-depend on git. What blocked me to do to for the moment is that I did not find an easy way to ignore the debian directory; I suppose that wiping out changes to the files during a "debian/rules clean" would break the principle of least surprise. Anyway, given that our infrastructure builds binary packages from a fresh unpacked source package, I would prefer if we keep the compromise that imperfect "clean" targets are not release-critical problems. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20130505010007.gb29...@falafel.plessy.net
