[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Modules packaging policy - call for discussion



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: