Re: Modules packaging policy - call for discussion

[Sven Luther <sven.luther@wanadoo.fr>]

On Tue, Mar 28, 2006 at 08:12:04PM -0800, Jurij Smakov wrote:
> On Sun, 26 Mar 2006, Sven Luther wrote:
> 
> [..]
> > 2) do not build module .udebs from out-of-tree packages, and let it be the
> > responsability of the d-i team to extract choice modules from those
> > out-of-tree modules .debs to be repackaged as .debs. I don't know if the 
> > d-i
> > team is ready to go that way, or thought of it.
> 
> Initially I was thinking that it's a good idea to have a super-package, 
> which will build all the binary modules from different module-source 
> packages for a given kernel. It was pointed out to me, that it will cause 
> certain problems, like there is going to be an extra headache of keeping 
> source and binaries in the archive in sync, and the interaction of this 
> package with binary modules which users might want to build themselves 
> from modules-source is going to be pretty cumbersome. During a brief 
> discussion on IRC Joey said that it would be acceptable for d-i team if 
> the binary modules would be built separately from the module-source 
> packages, as long as it is guaranteed that there will be an up-to-date 
> version for every kernel available in the archive. So everything is going 
> towards a system, in which binary modules are built from the module-source 
> packages by their respective maintainers/buildds, and we just need to work 
> out a system which will ensure that the binary modules will be uploaded in 
> a timely manner following a release. Bastian, as I understand, that's not 
> quite what you are proposing, it would be great if you could comment.

Notice that the important thing is that they are in sync with the kernel in
the testing archive. Unstable can (and will, no mather what) have version
skew, and uninstallable modules. This will be handled transparently by the
testing scripts, and the RMs have tools to detect such problematic modules,
and they can either be yanked from testing or NMUed if the maintainers are not
prompt enough, and a pure binNMU is not fast enough.

Friendly,

Sven Luther