Re: Modules packaging policy - call for discussion

[Max Vozeler <max@nusquama.org>]

On Thu, Mar 23, 2006 at 12:13:16AM -0500, Joey Hess wrote:
> Jurij Smakov wrote:
> > * 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.
> 
> The thing I really want to see is a way to guarantee that a binary
> module package will get updated in the debian archive when the kernel
> is changed. 

I'm currently doing module builds for both normal and udeb kernels
and need to keep them up-to-date by hand at the moment. A mechanism
to automate the rebuilds would be a huge improvement, but I don't
have a good idea how that could be accomplished.

> Until we have this guarantee, there's really no way the installer can
> reliably depend on out of tree modules that need to be used for
> anything during installation, and there's no way the installer can
> reliably cause these module packages to be installed on the target
> system.

>From a module packager perspective there are actually some more
difficulties involved in building module udebs:

  1. The version of linux-headers in unstable is sometimes ahead of
  the udeb kernel-image packages, like right now (2.6.15/2.6.16). I
  don't remember exactly when this last happened, but for example
  once linux-headers-2.6.15-* get removed from unstable, there will
  be no way to build updated module udebs for the kernel used by
  the installer. Or am I missing something -- and headers are now
  kept as long as udeb kernels exist for the same version?

  2. The information about flavours used in udeb kernels is not
  available in linux-headers. For normal flavours waldi's build
  infrastructure (and my homebrewn scripts) use the information in
  /usr/src/linux-headers-$VERSION/arch/ to look up available
  flavours. Information about udeb flavours cannot be looked up in
  the same way. So at the moment I maintain a list of udeb flavours
  by hand and watch d-i commits to notice changes [0]. 

It seems to me like both points could be resolved if kernel udebs
were possible to build from the linux-2.6 source package, but I
admit to not actually understanding what else that would imply.
This has already been discussed to some extent, hasn't it? 

cheers,
Max