Documentation< Previous | Contents | Next >
Applying a Patch
In one of our use cases, we have downloaded the pyrit source package and we want to apply a patch that we found in the upstream git repository. This is a common operation and it should always be simple. Unfortunately, patches can be handled in different ways depending on the source package format and on the Git packaging workflow in use (when Git is used to maintain the package).
With an Unpacked Source Package You have run apt source pyrit and you have a pyrit-0.
4.0 directory. You can apply your patch directly with patch -p1 < patch-file:
$ apt source pyrit
[...]
$ cd pyrit-0.4.0
$ wget https://github.com/JPaulMora/Pyrit/commit/14
➥ ec997174b8e8fd20d22b6a97c57e19633f12a0.patch -O /tmp/pyrit-patch
[...]
$ patch -p1 </tmp/pyrit-patch
patching file cpyrit/pckttools.py
$ apt source pyrit
[...]
$ cd pyrit-0.4.0
$ wget https://github.com/JPaulMora/Pyrit/commit/14
➥ ec997174b8e8fd20d22b6a97c57e19633f12a0.patch -O /tmp/pyrit-patch
[...]
$ patch -p1 </tmp/pyrit-patch
patching file cpyrit/pckttools.py
Hunk #1 succeeded at 53 (offset -1 lines).
$ dch --local buxy ”Apply patch to work with scapy 2.3”
Hunk #1 succeeded at 53 (offset -1 lines).
$ dch --local buxy ”Apply patch to work with scapy 2.3”
At this point, you have manually patched the source code and you can already build binary pack- ages of your modified version (see section 9.1.4, “Starting the Build” [page 231]). But if you try to build an updated source package, it will fail, complaining about “unexpected upstream changes.” This is because pyrit (like a majority of the source packages) uses the source format (see debian/source/format file) known as 3.0 (quilt), where changes to the upstream code must be recorded in separate patches stored in debian/patches/ and where the debian/patches/series file indicates the order in which patches must be applied. You can register your changes in a new patch by running dpkg-source --commit:
$ dpkg-source --commit
dpkg-source: info: local changes detected, the modified files are: pyrit-0.4.0/cpyrit/pckttools.py
Enter the desired patch name: fix-for-scapy-2.3.patch
dpkg-source: info: local changes have been recorded in a new patch: pyrit-0.4.0/debian/
➥ patches/fix-for-scapy-2.3.patch
$ tail -n 1 debian/patches/series
fix-for-scapy-2.3.patch
$ dpkg-source --commit
dpkg-source: info: local changes detected, the modified files are: pyrit-0.4.0/cpyrit/pckttools.py
Enter the desired patch name: fix-for-scapy-2.3.patch
dpkg-source: info: local changes have been recorded in a new patch: pyrit-0.4.0/debian/
➥ patches/fix-for-scapy-2.3.patch
$ tail -n 1 debian/patches/series
fix-for-scapy-2.3.patch
Quilt Patch Series This patch management convention has been popularized by a tool named quilt and the “3.0 (quilt)” source package format is thus compatible with this tool—with the small deviation that it uses debian/patches instead of patches. This tool is available in the package of the same name and you can find a nice tutorial here:
➨ https://raphaelhertzog.com/2012/08/08/
how-to-use-quilt-to-manage-patches-in-debian-packages/
Quilt Patch Series This patch management convention has been popularized by a tool named quilt and the “3.0 (quilt)” source package format is thus compatible with this tool—with the small deviation that it uses debian/patches instead of patches. This tool is available in the package of the same name and you can find a nice tutorial here:
➨ https://raphaelhertzog.com/2012/08/08/
how-to-use-quilt-to-manage-patches-in-debian-packages/
If the source package uses the 1.0 or 3.0 (native) source format, then there is no requirement to register your upstream changes in a patch. They are automatically bundled in the resulting source package.
With a Git Repository If you have used Git to retrieve the source package, the situation is even more complicated. There are multiple Git workflows and associated tools, and obviously not all Debian packages are using the same workflows and tools. The distinction already explained about source format is still relevant but you must also check whether patches are pre-applied in the source tree or whether they are only stored in debian/patches (in this case, they are then applied at build time).
The most popular tool is git-buildpackage. It is what we use to manage all repositories on git- lab.com/kalilinux/packages. When you use it, patches are not pre-applied in the source tree but they are stored in debian/patches. You can manually add patches in that directory and list them
in debian/patches/series but users of git-buildpackage tend to use gbp pq to edit the entire patch series as a single branch that you can extend or rebase to your liking. Check gbp-pq(1) to learn how to invoke it.
git-dpm (with associated command of the same name) is another git packaging tool that you can find in use. It records metadata in debian/.git-dpm and keeps patches applied in the source tree by merging a constantly-rebased branch that it builds out of the content of debian/patches.