debian/patches

This page stems from the following discussion on debian-devel in January 2008: [http://lists.debian.org/msgid-search/alpine.DEB.1.00.0801250818360.5187@wr-linux02 alpine.DEB.1.00.0801250818360.5187@wr-linux02]. It also includes ideas from the discussion [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=250202 #250202] about the Policy.

Existing systems

General caracteristics

Patch system

Location of the patches

How to inactivate a patch

Accepts diff -u output

Advantage

[http://packages.debian.org/dpatch dpatch]

debian/patches

Remove its name from debian/patches/00list

Header needs to be added

Can do scripting

[http://packages.debian.org/quilt quilt]

debian/patches

Remove its name from debian/patches/series

Yes

Suitable for generating patches on any size codebase. Advanced VCS-like features.

[http://packages.debian.org/cdbs cdbs] simple-patchsys

debian/patches

Remove its .diff or .patch suffix

Yes

Simple

[http://www.dpkg.org/dpkg/NewSourceFormat wig&pen]

debian/patches in .debian.tar.gz file

Rename to include a non-word non-hyphen character

Yes

Native to [http://packages.debian.org/dpkg dpkg]

[http://packages.debian.org/dbs dbs]

debian/patches

Remove it from the directory

Yes

Patches applied in ASCIIbetical order, no series file. Tarball-in-tarball (if you're in to that).

Packages using dpatch system can [http://blog.orebokech.com/2007/08/converting-debian-packages-from-dpatch.html be converted easily] to quilt system which has better supports by other softwares, e.g. guilt for git.

Patching/unpatching targets includeable in debian/rules

File

Package

To patch

To depatch

/usr/share/dpatch/dpatch.make

dpatch

patch

unpatch

/usr/share/quilt/quilt.make

quilt

patch

unpatch

/usr/share/cdbs/1/rules/patchsys-quilt.mk

quilt

apply-patches

reverse-patches

/usr/share/cdbs/1/rules/simple-patchsys.mk

cdbs

apply-patches

reverse-patches

/usr/share/cdbs/1/rules/dpatch.mk

cdbs

apply-dpatches

deapply-dpatches

Limitations

Users of a source package need the unpacked source not ready for compilation, but ready for inspection and modification. The two major use cases are application of (minor) local modifications (security fixes, compile time options) and manual or automated inspection of the source code (auditing, searching). This should be possible without installing additional packages besides dpkg-dev.

It has been discussed that the use of patch systems was making the work of porters, NMUers, security and QA teams difficult for several reasons:

  1. The profusion of patch systems. People would have to learn them all and to be able to detect which one is used in the package they are working on.
  2. The difficulty to repack the sources. If direct modifications of source pacakages block the target unpatch, and if this target is called by clean, dpkg-buildpackage will fail.

  3. It is unclear whether Wig&Pen will be implemented and if yes, when. Some patch systems are not yet adapted to this format yet.

  4. Documents such as /usr/share/doc/debian/source-unpack.txt do not warn that modifications to the freshly unpacked sources can break the patching step.

Proposed improvements

Rejected ideas

A radical solution: not using any patch system anymore

Keeping a whole package, including upstream sources, in a version control system (VCS) has been proposed as an alternative way to manage the modification to upstream sources.

Comparison between the two paradigms

debian/patches

VCSes

Changes to upstream sources are divided in logical blocks that are the patches.

Changes to upstream sources are divided into logical blocks that are groups of commits.

dpkg-buildpackage can fail after modifications of the sources

dpkg-buildpackage can not be blocked by the impossibility to unpatch the sources.

The diff.gz file only contains files located in the debian directory

Informations conveyed by defining groups of commits is not reflected in the diff.gz file.

Well documented in beginners tutorials, strong tradition in packaging teams.

No tutorials for beginners, new and not widespread yet.

Repositories can be limited to contain only the debian directory.

Need to keep the upstream sources in a VCS as well.

Some systems, such as dpatch allow scripting.

Changes are systematically applied.

Of course, the use of VCS have other advantages, but this table focuses on the perspective of their substitution to patch management systems.

Unanswered questions

Future directions

If a consensus emerges, a [http://dep.debian.net/ Debian enhancement proposal] could be written.