1
TODO list for 1.0 target, to be implemented in 0.99.x
1
TODO list for 1.0 target
2
2
========================
4
- support other patch-application methods than "patch", esp. combined
5
patch+cp (#118232, #129459) - be careful on unpatch. See description
6
of "revision 1" format in the doc.
8
- support for concurent patch files for one kernel
9
(eg: 2.2.14-vanilla vs. 2.2.14-with-rtai-1.3)
11
Kernel-version: 2.2.14
14
- a utility to display available versions of patches
4
Those will be implemented in 0.100.x, and 0.99.x will not see any new
5
developments, only bugfixes.
9
- when a patch version is selected through the environment, propagate
10
it to dependencies to be applied (unless env was used for the dep),
11
and maybe check deps that were already applied.
14
* core v1 functionality
16
- complete transition of internal data structures to v1:
17
- modularisation of operations
19
- generalize apply/unpatch scripts and put them in
20
kernel-patch-scripts package, for space-saving and to allow
21
collaborating packages (see #118122), so that kpatch packages need
22
only install symlinks to them. But above all, this is on one of the
23
path to v1 implementation, so ...
25
- rewrite apply/unpatch in perl, since the code of those will be
26
mixed with the current dh_installkpatches script, to reach the above
29
- support other operations than "diff application", esp. combined
30
diff+cp (#118232, #129459) - be careful on unpatch (see description of
31
"revision 1" format in the doc).
33
- support kernel flavours (see description of "revision 1" format in
16
39
- review the kpatches-specs and kpatch-policy documents, and manpage.
24
47
(possibly) post-1.0 TODO list
25
48
=============================
27
- rewrite apply/unpatch in perl
29
- kernel-patch-common package, for space-saving and collaborating
30
packages (see #118122)
50
- generate a ${Kernel:versions} substvar, to make it possible to
51
automagically maintain a useful package description.
53
- provide a way to hide patches that are not meant to be used
54
directly, but only depended upon (eg. kdbcore, evms-*), so that they
55
do not uselessly cripple lskpatches output by default (possibly
56
applies to the contents of applied-patches list as well).
58
- provide a make-kpatch-pkg tool to help users in building Q&D kpatch
59
packages for their internal use (I was not sure it was worth doing it,
60
but at least one make-kpkg user requested the feature)
62
- provide a dh_make template for helping to build official patch
32
65
- tarfile support may require pax(1) to get Path-strip-level support
37
70
- support for open kversion ranges, and enumerated. Something like:
38
71
Kernel-version: 2.4.15 - (meaning: all 2.4 kernels starting at .15)
39
72
Kernel-version: 2.2.10 -, 2.4.5 -
73
Kernel-version: 2.4 (meaning: all versions in the 2.4 era)
75
That will require sophisticated version-comparison rules, to
76
accomodate well-known EXTRAVERSION prefixes (yes, upsteam-shipped
77
EXTRAVERSION is the prefix of the suffix ;), ie. "test" and "pre"
78
(-ac, -aa, -dj and such are better seen as flavours)
added
removed
TODO
