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.
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
.
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/
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.
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.
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.
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.
Kernel-patch sub-policy draft document
$Revision: 1.5 $dirson@debian.org