Provided by: dpatch_2.0.30_all
dpatch.make - simplistic wrapper around dpatch(1) for make(1).
For backwards compatibility and ease of use, dpatch.make is provided
along with dpatch(1). Its purpose is to implement generic patch and
unpatch rules that can be reused in debian/rules scripts.
Using dpatch.make is rather straightforward: one has to include the
file in debian/rules, change the appropriate targets to depend on patch
and unpatch, and that is all it takes.
Figuring out what the appropriate target is, requires some thought.
Generally, one has a build target, or config.status, or configure (or
any of these with a -stamp suffix). Most of the time these are called
first during the build, so one of these (the one that exists, and is
not depended upon by another one) has to be modified to depend on the
patch target in dpatch.make.
Doing the same for the clean target is easier. One only has to rename
the old rule to, say, clean-patched, then make a new one that has
clean-patched and unpatch in its list of prerequisites.
There are a few variables which are used by dpatch.make, which can be
set before including it, in order to change the systems behaviour a
These variables are:
This is the name of the source package, used when
creating the stamp file. By default, it is empty.
This is the directory where stamp files will be put.
Default is debian/patched.
The name of the stamp file, which contains the patch
descriptions and other possible meta-data. Default value
The target directory to apply patches to. By default, it
is the current directory.
The list of patches to apply. This is an alternative to
debian/patches/00list - that is, if this variable is not
empty, the contents of 00list will be ignored, and this
variable will be used instead.
clean: clean1 unpatch
rm -rf debian/files debian/substvars debian/imaginary-package
.PHONY: patch unpatch ...
Using dpatch.make instead of calling dpatch directly has one side
effect: it will create a file called patch-stamp containing some
meta-information extracted from the scriptlets.
Depending on a phony patch target directly from build target may cause
build target to be reevaluated even when there is no change to be done.
Instead, try making build-stamp depend on patch-stamp as specified in
Originally by Gergely Nagy. Modified by Junichi Uekawa.
dpatch(1), dpatch(7), dpatch-edit-patch(1), dpatch-list-patch(1),