Re: debuild/dpkg-buildpackage behaves not as expected
debian-devel@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
Reply to: