Modules packaging policy - call for discussion
Hi,
It is pretty obvious (to me, at least) that the need for the official
packaging policy for the out-of-tree kernel modules is long overdue. As
mentioned on the wiki page dedicated to it [0], the current situation is a
mess. I would like to call for a formal discussion, which will eventually
lead to the formulation of such policy. As a first step I propose to just
throw the ideas around and figure out what we want the module infra-
stracture to be capable of. Then, we can discuss technical aspects
of it, and prepare a draft policy.
Below are the things I would like to see implemented in module building
infrastructure. Note that I do not maintain any module packages myself, so
my opinions and proposals might be naive in some aspects, so feel free to
correct.
* Unified way to build the modules. I think module-assistant is the sanest
way to implement it in a reasonable time frame.
* Automatic rebuilds (configurable) on kernel updates. Nothing fancy, just
a transparent way to figure out whether the currently installed
kernel module source is compatible with the new kernel, and attempt
rebuild and installation, if neccessary.
* Robustness. Packaged kernel modules *must* build against official kernel
headers packages. I am aware of at least one module (lirc), which requires
additional header files which we currently do not ship in linux-headers.
That's probably broken since such modules are not using the publicly
exported kernel API, so it's probably fair to require that they either get
fixed or include necessary files in the module source package.
* Flexibility. It should be possible to build against *any* kernel tree
or a custom-build linux-headers package, if user so desires, with minimum
hassle. The wiki page [0] has a great deal to say about it, everything
mentioned there on the topic seems sane to me.
[0] http://wiki.debian.org/KernelModulesPackaging
Best regards,
Jurij Smakov jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
Reply to: