TODO list for 1.0 target
========================

Those will be implemented in 0.100.x, and 0.99.x will not see any new
developments, only bugfixes.

* dependency handling

- when a patch version is selected through the environment, propagate
it to dependencies to be applied (unless env was used for the dep),
and maybe check deps that were already applied.


* core v1 functionality

- complete transition of internal data structures to v1:
 - modularisation of operations

 - generalize apply/unpatch scripts and put them in
 kernel-patch-scripts package, for space-saving and to allow
 collaborating packages (see #118122), so that kpatch packages need
 only install symlinks to them.  But above all, this is on one of the
 path to v1 implementation, so ...

 - rewrite apply/unpatch in perl, since the code of those will be
 mixed with the current dh_installkpatches script, to reach the above
 point.

- support other operations than "diff application", esp. combined
diff+cp (#118232, #129459) - be careful on unpatch (see description of
"revision 1" format in the doc).

- support kernel flavours (see description of "revision 1" format in
the doc).


* sanity stuff

- review the kpatches-specs and kpatch-policy documents, and manpage.

- maybe make dh_inst check build-deps versionning

- make dh_installkpatches validate the fields in the kpatches file, so
that wished features do not get reported as bugs :)


(possibly) post-1.0 TODO list
=============================

- generate a ${Kernel:versions} substvar, to make it possible to
automagically maintain a useful package description.

- provide a way to hide patches that are not meant to be used
directly, but only depended upon (eg. kdbcore, evms-*), so that they
do not uselessly cripple lskpatches output by default (possibly
applies to the contents of applied-patches list as well).

- provide a make-kpatch-pkg tool to help users in building Q&D kpatch
packages for their internal use (I was not sure it was worth doing it,
but at least one make-kpkg user requested the feature)

- provide a dh_make template for helping to build official patch
packages

- tarfile support may require pax(1) to get Path-strip-level support

- support for use of make-kpkg's versionning (eg. Version-sensitive:
yes) ?

- support for open kversion ranges, and enumerated.  Something like:
Kernel-version: 2.4.15 -	(meaning: all 2.4 kernels starting at .15)
Kernel-version: 2.2.10 -, 2.4.5 -
Kernel-version: 2.4		(meaning: all versions in the 2.4 era)

That will require sophisticated version-comparison rules, to
accomodate well-known EXTRAVERSION prefixes (yes, upsteam-shipped
EXTRAVERSION is the prefix of the suffix ;), ie. "test" and "pre"
(-ac, -aa, -dj and such are better seen as flavours)
