Re: Modules packaging policy - call for discussion
- To: debian-kernel@lists.debian.org
- Subject: Re: Modules packaging policy - call for discussion
- From: Andres Salomon <dilinger@debian.org>
- Date: Thu, 23 Mar 2006 02:10:44 -0500
- Message-id: <dvthll$6fm$1@sea.gmane.org>
- In-reply-to: <Pine.LNX.4.63.0603222008391.3695@bobcat>
- References: <Pine.LNX.4.63.0603222008391.3695@bobcat>
Jurij Smakov wrote:
> 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.
Agreed. M-a has documentation that describes how to package your third
party module. We should also make it policy that module source packages
should simply create <modname>-source; it should have no binary modules
created. Other stuff should take care of that.
That "other stuff" is what I'm interested in, at this point; waldi
claims to be working on stuff[0]. Waldi, can you please expand upon
that? It would be nice to automate binary module package creation when
a new kernel is released. The last I heard, this was planned by making
the buildds automatically rebuild packages. If that is the case, who
will be handling the source packages for those binary module packages?
>
> * 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.
Our policy on this has always been that they should simply include the
necessary files in the module source package.
[0] http://lists.debian.org/debian-devel/2006/03/msg00801.html
Reply to: