4736
Comment: Suggestion from a private mail of Teemu Likonen.
|
5929
Incorporate ideas from #250202; other updates as well.
|
Deletions are marked like this. | Additions are marked like this. |
Line 4: | Line 4: |
[http://lists.debian.org/msgid-search/alpine.DEB.1.00.0801250818360.5187@wr-linux02 alpine.DEB.1.00.0801250818360.5187@wr-linux02]. | [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. |
Line 17: | Line 17: |
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. |
|
Line 21: | Line 23: |
2. The difficulty to repack the sources. If direct modifications of source pacakages block the target ''unpatch'', {{{dpkg-buildpackage}}} will fail. | 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. |
Line 25: | Line 27: |
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. |
|
Line 27: | Line 31: |
* 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. | |
Line 30: | Line 35: |
* Make {{{dpkg-source}}} apply the patches automagically after unpacking the sources, but using its own internal procedures for security (at this stage, it is not known if running 'debian/rules patch' is safe or not; {{{dpkg-source}}} is also used on non-official packages such as the ones proposed for sponsoring. | * Make {{{dpkg-source}}} apply the patches automagically after unpacking the sources (using internal procedures). |
Line 32: | Line 37: |
* 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 intrduced. == Rejected ideas == * Make {{{dpkg-source}}} call the patching rule: * This is a security threat; * it would require the build-dependancies of a package to be installed. |
|
Line 57: | Line 70: |
* Is there somebody working on the Wig&Pen format ? |
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
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 |
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] |
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
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 two main reasons:
- 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.
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.
It is unclear whether Wig&Pen will be implemented and if yes, when. Some patch systems are not yet adapted to this format yet.
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.
- "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 intrduced.
Rejected ideas
Make dpkg-source call the patching rule:
- This is a security threat;
- it would require the build-dependancies of a package to be installed.
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. |
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?
Is there somebody working on the Wig&Pen format ?
Future directions
If a consensus emerges, a [http://dep.debian.net/ Debian enhancement proposal] could be written.