[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ next ]

Kernel-patch sub-policy draft document
Chapter 3 - Scripts naming and behaviour


This section is meant to give guidelines for writing the apply and unpatch in a way that will work securely (ie. doesn't break the current kernel-source tree), and will integrate smoothly with the remaining of the system.

This is where currently packaged patches tend to behave in unwanted ways.


3.1 Naming

Unless specific patches are requested, scripts in the apply and unpatch dirs are executed via run-parts, which runs them in lexical sort order.

It may be nice at some time to allow the names of applied patches to make their way to the EXTRAVERSION field in the kernel revision, so that we get kernel versions like "2.2.17+ide+ltt+int", that would automagically provide at the same time instant information for what patches were applied, and the ability of also installing at the same time plain "2.2.17" as well as "2.2.17+kdb+reiserfs" (no offense to reiserfs meant ;). It may be nice at this time to have patches provide such a short name to make-kpkg.


3.2 Behaviour

Most of the scripts share a number of behaviours that help them to acomplish the task that justifies their existence. However, probably for lack of such a document, they are currently built on an ad-hoc basis, starting with a copy of existing scripts. I'll try here to list those behaviours and give guidelines so that they indeed do not interfere with each other.

As of now, I don't think a single patch package (including mines) behaves correctly in all these areas. I have started a debhelper-like script to help in this area and to provide a couple additional functionalities. Those interested will find it at http://people.debian.org/~dirson/kpatches/


3.2.1 apply telling unpatch the patch was applied

This is usually done by creating a file named debian-patches/APPLIED_patchname, which unpatch checks to know whether it has something to do, and which apply also checks to not try to re-apply itself.

Some patches create this file in the debian/ subdirectory, and some other patches create it at the top-level of the kernel sources. The former causes interferences between make-kpkg clean operation and patches applied by running apply scripts by hand; the latter causes problems because some apply scripts remove empty files after patching. Further more, these files are debian-specific, so they may be better in debian-specific subdir anyway.


3.2.2 Removing empty files after patching

This is mostly done to cleanup the source tree in cases where files were suppressed or moved. Most package just run find on the whole source tree to find them, then remove them, and create an empty APPLIED_whatever as described above... which gets happily removed by the next apply script that gets run.

For good interaction between those 2 behaviours, no empty files should be removed from the debian/ subdirectory - anyway no file there should be removed by any patch I can think of, as this dir is not part of an official kernel tree. This will allow APPLIED_whatever scripts conforming to the previous point to survive to play their role in the whole picture.


3.2.3 Checking whether to apply the patch

apply scripts, when they determine with whatever means that they should not attempt to apply, should not return an error code. This allows unversionned patches to be applied as long as patch can do the job, without preventing other patches to apply on versions of the kernel on which they don't themselves apply.


3.2.4 Not breaking the source tree

The scripts should make sure they won't break the user's tree, by using patch --dry-run before they really apply the patch. Not only does this allow unversionned patches to exist at all without enforcing version tests in the scripts, but it also allows the user to experiment with stacking patches without having to restart from unpacking the source at each failure.


[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ next ]

Kernel-patch sub-policy draft document

$Revision: 1.5 $
Yann Dirson dirson@debian.org