Re: modules

[dann frazier <dannf@dannf.org>]

On Sat, 2005-09-03 at 23:28 +0200, Sven Luther wrote:
> On Sat, Sep 03, 2005 at 09:10:14PM +0200, Bastian Blank wrote:
> > On Sat, Sep 03, 2005 at 08:45:07PM +0200, Sven Luther wrote:
> > > Why not fix the module-package so they build those binary modules themselves ? 
> > 
> > It makes it possible to build the correct packages, but it does not
> > address the problem that this needs regular uploads of all of the
> > packages which I want to fix with this.
> > 
> > We already did the same step with the images themself, so why not do it
> > with modules?
> > 
> > > BTW, i am curious, how can a wireless chip be "highly" wireless :)
> > 
> > s/wireless/used/, better?
> > 
> > > > It may also contain sources themself. (One example may the ibmvscsis,
> > > > which is needed on several pSeries machines but never released and
> > > > Ganneff may kill me if I want to add a package with 5 source files.)
> > > I am not entirely sure i agree on this. 
> > 
> > Please explain.
> 
> Well, my idea is to try to host all those module package in the kernel
> subversion tree (under modules), in such a way that we can trigger automated
> or semi-automated uploads of them in case of kernel abi changes.

some food for thought...
kernel-images I maintain for work[1] will build-dep on all associated
kernel-module-source packages and spit out separate debs for these
modules automatically as part of the build.  This works well for us,
because we never have to do manual (or semi-auto) builds of all these
other module packages.  If their source doesn't need to change, then
they don't have to be re-released, and they're always built against the
latest headers.

Of course, doing something similar in the kernel team would have a
significant number of negative aspects.  The kernel team would become
the de facto maintainers for these modules.  Not only would the
maintenance overhead add extra load, but we'd have to deal with rc bugs
in these modules keeping us from migrating into testing, etc.

But.. is there a way to do something similar and avoid these problems?
Like maybe a kernel-modules-outoftree source package that build-deps on
all current source?  Or, maybe we do let linux-2.6 do these builds, but
with a policy of tough love for those with RC issues (no questions asked
removal until they're shown to no longer have problems)?

I find the requirement to do a new release of a package just for a
rebuild pretty ugly - there's gotta be a better way.

[1] Here's an example:
http://hpde.linux.hp.com/hpde/1.2/pool/updates/hpde/k/kernel-image-2.4.25-hpe/
The source to qsnetmodules is provided by a separate package - make-kpkg
--added-modules is used to spit out the binaries as part of the k-i
build.