Re: kernel-{image,headers} package bloat breaks module builders
[I'm responding to Herbert directly to draw attention to this question
and make sure I get a response from him. I have also read the rest of
this thread even though I am responding to a fairly early message. ]
I'm approaching this as the maintainer of the openafs package, which
has a kernel module. I suspect other module package maintainers
(PCMCIA, ALSA, etc) will have similar issues.
I am concerned about the work that this new kernel image organization
may create as well as the additional load on the mirrors potentially
placed by this scheme. My assumption is that there will be different
modversions for each kernel configuration and that as such, I will
need to build binary modules packages against each kernel image. If
you can guarantee that this is not the case and will not be the case,
then my module-specific concerns go away. Even if you accept that the
bandwith usage/mirror load/distribution size increase simply from the
kernel packages is acceptable, it is not clear that multiplying the
number of packages (and thus to an extent some size multiplier) by the
number of module packages is also acceptable. Assuming that the
number of module packages no in the kernel continues to increase,
which I think likely, the problem will only get worse over time.
I also am concerned about the amount of work this creates for module
maintainers. Now I have to rebuild a lot of packages both when my
upstream sources change and when the kernel images change. I had to
do this already, but the effort involved is significantly less. I now
have to look and make sure the set of images hasn't changed, retrieve
the sources (kernel headers packages don't look enough like source
trees to satisfy make-kpkg), configure the kernel trees, which
involves grabbing the configs from somewhere (either kernel images or
the source package) and build modules for each kernel image.
The binary modules packages (alsa and pcmcia) especially although I
haven't been doing much better of late tend to have an annoying
history of not being in sync with the kernel. I'm concerned that this
could make things worse. Personally as a user (who has used stock
kernel images wherever possible) I'd much rather have modules packages
that work than lots of kernel images to choose from.
Reply to: