debian-de...@liska.ath.cx (Olе Streicher) writes: > Hi, > > I just discovered that debuild does not behave as I would expect from > the maintainer's guide [1]: > > | Cleaning the source and rebuilding the package from your user account > | is as simple as: > | $ debuild > [...] > | You can clean the source tree as simply as: > | $ debuild clean > > This gives an error if the "dh_clean" does not work on the unpatched > source, since "debuild" reverts all patches, but "debuild clean" does > not apply then. I filed a bug report for this [2], including a simple > example package, but the maintainer doesn't see a problem here. > > For me, the behaviour doesn't look good since the state after "debuild" > does not make sense to me: all files created during the build process > (from the patches sources) are still there (including temporary ones), > but the sources themself do not are not patched anymore. So, build > results and sources do not fit together after this step. Even more, if > during the build process one file that has a Debian patch is changed, > unapplying the patch may fail even if the build change would be reverted > during the clean process. > > What is the rationale behind the automatic reversal of the applied > patches before a cleanup?
What automatic reversal? There is no automatic reversal. The default state of source is with patches applied. % ddsa_0.1-1.dsc dpkg-source: warning: extracting unsigned source package (ddsa_0.1-1.dsc) dpkg-source: info: extracting ddsa in ddsa-0.1 dpkg-source: info: unpacking ddsa_0.1.orig.tar.gz dpkg-source: info: unpacking ddsa_0.1-1.debian.tar.gz dpkg-source: info: applying automake % cd ddsa-0.1/ % debuild ... dpkg-genchanges: including full source code in upload dpkg-source --after-build ddsa-0.1 dpkg-buildpackage: full upload (original source is included) % debuild clean dh clean --with autoreconf dh_testdir dh_auto_clean make[1]: Entering directory `/data/home/brederlo/src/ddsa/ddsa-0.1' test -z "" || rm -f test . = "." || test -z "" || rm -f rm -f config.status config.cache config.log configure.lineno config.status.lineno rm -f Makefile make[1]: Leaving directory `/data/home/brederlo/src/ddsa/ddsa-0.1' dh_autoreconf_clean dh_clean dpkg-source leaves the source in the same state it finds it before build. So if you start out with patches applied then they stay applied. If you manually removed the patches then it is your job to manually apply them again. Wether debuild <target> should apply patches before running the target is arguable. But lets say it does apply patches before the target and then restores the source to the state it was before after the target. What happens if you now call debuild patch to apply the patches in a 3.0 (quilt) package that has patch/unpatch targets? Patches would be applied before that patch target is called, then patch is called and does nothing (or fails) and then patches are unapplied again to restore the original state. Not what you want. As a solution to your problem I would add patch/unpatch targets to your source file like this: QUILT=QUILT_PATCHES=debian/patches quilt --quiltrc /dev/null PATCH := $(QUILT) push -a || [ "$$($(QUILT) applied)" = "$$(grep -v '^\#' debian/patches/series)" ] UNPATCH := $(QUILT) pop -a || [ "$$($(QUILT) applied 2>&1)" = "No patches applied" ] patch: $(PATCH) unpatch: $(UNPATCH) configure-stamp: $(PATCH) ... build: build-stamp build-stamp: configure-stamp $(PATCH) ... clean: $(PATCH) ... # if you like sources unpatched use unapply-patches in # debian/source/local-options or: # $(UNPATCH) The reason for calling PATCH/UNPATCH directly instead of as dependencies is so that (un)patch is called again even if it was called before (because (un)patch might have been called since then) and so that targets with stamp files don't run every time. MfG Goswin -- 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/87r4ukp7ts.fsf@frosties.localnet