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

Re: Modules packaging policy - call for discussion



On Wed, Mar 22, 2006 at 08:32:06PM -0800, 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.

My position on this has always been that we should have a single source
package, which should build binary modules (and eventually .udebs) for all
official kernels, and then add a -source package which can be used via
kernel-pacakge or module-assistant, or another such tool. Those tools will
become of less use than now for those using official kernels though.

I believe Bastian is already working on this, and it is already implemented
for the non-free modules, altough documentation is needed, and integrationm
with debhelper, in order to facilitate module packaging.

But then, i will not be working on this, just wanted to give you my point, and
wish you all good luck with the implementation of it.

(BTW, do we have any kind of feedback about the 2.6.16 powerpc kernels, and
know if the ARCH=powerpc move for 32bit kernes didn't break module builds ? I
know that at least the highmem.h bug in 2.6.16 broke mol builds).

Friendly,

Sven Luther



Reply to: