This section should describe possible scopes for a patch in terms of kernel architecture and versions, and what actions to take depending on effective scope.
As you may infer from the previous chapter, some patches are fully generic, whereas others only apply to specific kernel versions and/or specific architectures.
Some patches do not include support for some achitectures, in which case all they can bring to other architectures is to break them in one way or another. Then they need to be restricted into architecture-dependant directories. In the case where a patch applies to several architectures, shared files should be hard-linked to avoid wasting disk space.
Only patches with (at least theoretical) support for all architectures, and non-architecture-dependant patches, belong to the all category.
Usually patches are made of a diff file. These diff files are usually built by
comparing a specific kernel-source tree and a modified tree. Although those
diffs are guaranted to apply on a tree identical to the one which served as
reference when the diff was built, they may also apply (in the mechanical
meaning defined by patch
returning success) to a number of kernel
revisions (or kernels with other patches already applied), if the areas touched
by the patch are similar enough to those in the reference tree. This means
that a patch against revision x.y.z may also apply to
x.y.(z-2) or x.y.(z+5) without patch
complaining.
However, this mechanical meaning of a patch applying is not enough in some cases, where changes in one area may interfere with changes in another. Such interferences will range from kernel not being able to compile (eg. because of struct members renamed or previously exported functions marked static) to kernels behaving in really strange unforeseen ways, possibly causing data corruption or all other types of behaviour you usually want to run away from.
For these reasons, depending on how tricky a patch is, one may want to limit
the range of kernel versions on which it is to be applied. For this the
version-specific subdirectories of /usr/src/kernel-patches/
have
been created. But beware not to be too limitative, a patch against the latest
stable kernel may well be useful with the next yet-unreleased one, and you may
not want to be totalitarian with your package's users. Up to you to make a
"good choice", whatever that means.
Kernel-patch sub-policy draft document
$Revision: 1.5 $dirson@debian.org