Differences between revisions 4 and 5
Revision 4 as of 2008-01-30 21:12:31
Size: 1851
Editor: BenHutchings
Comment: Happy new year!
Revision 5 as of 2008-02-01 01:10:07
Size: 4388
Comment: Summary of the current discussions.
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:

== Existing systems ==
Line 13: Line 15:
== Limitations ==

It has been discussed that the use of patch systems was making the work of porters, NMUers, security and QA teams difficult for two main 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'', {{{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.

== Proposed improvements ==

 * Standardise the interface of the patch systems.
 * Use a single wrapper, possibly mandatory.
 * "Qualify" the systems which are widespread and durable, and discourage the use of others.

It also has been discussed whether {{{dpkg-source}}} or equivalents could call the ''patch'' target automagically. However, in the case of unofficial packages, such as those reviewed for sponsoring, this would cause security problems for which the inconvenience of the answers make the proposition lose its interest.


== A radical solution: not using any patch system anymore ==

=== 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. ||
|| Not very convenient for very big projects. || Well adapted to big projects. ||


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

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

 * The repository of packaging teams can contain up to hundreds of packages. How can they stay slim if they must contain upstream sources?
Line 15: Line 58:
It has been discussed that the profusion of patch systems was making the work of porters, NMUers, security and QA teams difficult, and that some kind of standardisation would be useful. For instance, the systems could be wrapped and one single interface could be provided. Policy could describe how to use rules such as ''patch'' and ''unpatch'' to provide such a single interface.

Alternatively, it has been proposed to not use patch systems and store this information in version control systems instead.

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

Existing systems

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

No

Can do scripting

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

debian/patches

Remove its name from debian/patches/series

Yes

Can reorder patches

[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).

Limitations

It has been discussed that the use of patch systems was making the work of porters, NMUers, security and QA teams difficult for two main 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, 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.

Proposed improvements

  • Standardise the interface of the patch systems.
  • Use a single wrapper, possibly mandatory.
  • "Qualify" the systems which are widespread and durable, and discourage the use of others.

It also has been discussed whether dpkg-source or equivalents could call the patch target automagically. However, in the case of unofficial packages, such as those reviewed for sponsoring, this would cause security problems for which the inconvenience of the answers make the proposition lose its interest.

A radical solution: not using any patch system anymore

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.

Not very convenient for very big projects.

Well adapted to big projects.

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

  • 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?
  • The repository of packaging teams can contain up to hundreds of packages. How can they stay slim if they must contain upstream sources?

Future directions

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