Differences between revisions 23 and 40 (spanning 17 versions)
Revision 23 as of 2009-07-02 02:45:01
Size: 7613
Comment: Mention $(QUILT_STAMPFN).
Revision 40 as of 2020-02-28 00:49:28
Size: 8354
Editor: nodiscc
Comment: CategoryPackaging
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
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.
This page stemmed from the following discussion on debian-devel in January 2008:
<<mid(alpine.DEB.1.00.0801250818360.5187@wr-linux02)>>. It also includes ideas from the discussion [[DebianBug:250202|#250202]] about the Policy.

'''Note''': The patch format itself is now a formal [[DEP]], [[http://dep.debian.net/deps/dep3/|DEP-3: Patch Tagging Guidelines]].
Line 8: Line 10:
=== General caracteristics === === General characteristics ===
Line 11: Line 13:
||[[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/dpatch|dpatch]] ([[http://lists.debian.org/debian-devel/2011/08/msg00380.html|deprecated]])||{{{debian/patches}}}||Remove its name from {{{debian/patches/00list}}}||Header needs to be added||Can do scripting||
Line 13: Line 15:
||[[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).||
||DebPkg:cdbs simple-patchsys (deprecated since 0.4.85)||{{{debian/patches}}}||Remove its {{{.diff}}} or {{{.patch}}} suffix||Yes||Simple||
||[[http://www.dpkg.org/dpkg/NewSourceFormat|2.0 a.k.a. wig&pen]] (obsolete, use 3.0 quilt)||{{{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]] as 2.0 format||
||[[Projects/DebSrc3.0|3.0 (quilt)]]||{{{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]] as 3.0 (quilt) format||
||[[http://packages.debian.org/dbs|dbs]] ([[http://packages.debian.org/changelogs/pool/main/d/dbs/current/changelog#versionversion0.47|deprecated]])
||{{{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).||
Line 17: Line 20:
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}}}. Packages using '''dpatch''' system can [[https://pyxon.wordpress.com/2010/01/14/converting-debian-packages-from-dpatch-to-quilt/|be converted easily]] to '''quilt''' system which has better supports by other softwares, e.g. {{{guilt}}} for {{{git}}}.
Line 20: Line 23:

Thanks to the cooperation of them maintainers of dpatch, quilt and CDBS, {{{patch}}} and and {{{unpatch}}} targets became standard.
Line 24: Line 29:
||/usr/share/cdbs/1/rules/patchsys-quilt.mk || quilt || apply-patches || reverse-patches || ||/usr/share/cdbs/1/rules/patchsys-quilt.mk || quilt || patch         || unpatch         ||
Line 38: Line 43:
 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.  2. The difficulty to repack the sources. If direct modifications of source packages block the target ''unpatch'', and if this target is called by ''clean'', {{{dpkg-buildpackage}}} will fail.
Line 40: Line 45:
 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.  3. This approach is not compatible with the [[Projects/DebSrc3.0|3.0 (quilt)]] format.
Line 48: Line 53:
 * Use a single wrapper, possibly mandatory.  * Use a single wrapper, possibly mandatory.Bugs: DebianBug:4588 et. al.
Line 53: Line 59:
 * Implement a target called ''patched'', that provides sources in such a state that calling {{{debian/rules binary}}} will not revert changes intrduced.  * Implement a target called ''patched'', that provides sources in such a state that calling {{{debian/rules binary}}} will not revert changes introduced.
Line 59: Line 65:
  * it would require the build-dependancies of a package to be installed.   * it would require the build-dependencies of a package to be installed.
  * Instead {{{dpkg-source}}} does the patching itself in the [[Projects/DebSrc3.0|3.0 (quilt)]] format that was implemented in the meantime.
Line 79: Line 86:
=== Unanswered questions === === Previous unanswered questions ===
Line 83: Line 90:
 * The repository of packaging teams can contain up to hundreds of packages. How can they stay slim if they must contain upstream sources? == Current situation ==
Line 85: Line 92:
 * Is there somebody working on the Wig&Pen format ? At the time of dpkg 1.14.17 release, 3.0 format was included and Bugs: DebianBug:4588 et. al. was closed.
Line 87: Line 94:
== Future directions == ### ----
### CategoryObsolete dpkg-source v3 obsoletes this, should delete after lenny
Line 89: Line 97:
If a consensus emerges, a [[http://dep.debian.net/|Debian enhancement proposal]] could be written. ### Due to the slow turnover of some packages, I am afraid that this information
### will not be obsolete immediately after Lenny release.
### Please at least give me some time to backup the page before deleting it.
### -- CharlesPlessy


### I think this page should stay. Updated contents to reflect it to current state.
### -- OsamuAoki
Line 92: Line 107:
CategoryObsolete dpkg-source v3 obsoletes this, should delete after lenny

  Due to the slow turnover of some packages, I am affraid that the informations
  will not be obsolete immediately after Lenny release.
  Please at least give me some time to backup the page before deleting it.
  -- CharlesPlessy
CategoryDebianDirectory | CategoryPackaging

debian/patches

This page stemmed from the following discussion on debian-devel in January 2008: <alpine.DEB.1.00.0801250818360.5187@wr-linux02>. It also includes ideas from the discussion #250202 about the Policy.

Note: The patch format itself is now a formal DEP, DEP-3: Patch Tagging Guidelines.

Existing systems

General characteristics

Patch system

Location of the patches

How to deactivate a patch

Accepts diff -u output

Advantage

dpatch (deprecated)

debian/patches

Remove its name from debian/patches/00list

Header needs to be added

Can do scripting

quilt

debian/patches

Remove its name from debian/patches/series

Yes

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

cdbs simple-patchsys (deprecated since 0.4.85)

debian/patches

Remove its .diff or .patch suffix

Yes

Simple

2.0 a.k.a. wig&pen (obsolete, use 3.0 quilt)

debian/patches in .debian.tar.gz file

Rename to include a non-word non-hyphen character

Yes

Native to dpkg as 2.0 format

3.0 (quilt)

debian/patches in .debian.tar.gz file

Rename to include a non-word non-hyphen character

Yes

Native to dpkg as 3.0 (quilt) format

dbs (deprecated)

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 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

Thanks to the cooperation of them maintainers of dpatch, quilt and CDBS, patch and and unpatch targets became standard.

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

patch

unpatch

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

cdbs

patch

unpatch

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

cdbs

patch

unpatch

Note that in the case of quilt it may be better to use $(QUILT_STAMPFN) since patch is a phony target.

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 packages block the target unpatch, and if this target is called by clean, dpkg-buildpackage will fail.

  3. This approach is not compatible with the 3.0 (quilt) format.

  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

  • Simply document how to patch the sources in a file called README.source, a template of which could be provided in the package of the patch system used.

  • Standardise the interface of the patch systems.
  • Use a single wrapper, possibly mandatory.Bugs: 4588 et. al.

  • "Qualify" the systems which are widespread and durable, and discourage the use of others.
  • Make dpkg-source apply the patches automagically after unpacking the sources (using internal procedures).

  • Alternatively, make dpkg-source issue an informative message if it detects that a patch system is used.

  • Ship the sources patched (the clean target would call patch). Drawback: it bloats the diff.gz.

  • Implement a target called patched, that provides sources in such a state that calling debian/rules binary will not revert changes introduced.

Rejected ideas

  • Make dpkg-source call the patching rule:

    • This is a security threat;
    • it would require the build-dependencies of a package to be installed.
    • Instead dpkg-source does the patching itself in the 3.0 (quilt) format that was implemented in the meantime.

Using a VCS (instead of patch system) to track changes

Keeping a whole package, including upstream sources, in a version control system (VCS) is often used as a method of managing 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. Not true in my experience. What's the justification for this assertion? --BenFinney

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.

  • I track my packaging changes in a VCS, and am not required to keep upstream source in VCS. What prevents users of a VCS from keeping only debian/ in the VCS repository, and using e.g. bzr-buildpackage --merge to merge with the separate upstream source? --BenFinney 2008-10-06

Previous unanswered questions

  • Groups of commits can be more messy that a well-documented patch: while a patch can be modified, a commit can only be reverted by another commit, adding even more complexity to the group of commit. How can the information contained in the logical breakdown of the modifications to upstream in a set of patches can be conveyed in the VCS paradigm?

Current situation

At the time of dpkg 1.14.17 release, 3.0 format was included and Bugs: 4588 et. al. was closed.


CategoryDebianDirectory | CategoryPackaging