[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.
