I'm answering a bit late, but after rethinking, I don't see what's that wrong with that approach.
Le dim 25/05/2003 à 11:33, Herbert Xu a écrit : > That is an advantage. However, it also means that any update to the > modules source package cannot be built until another entire > kernel-image set is built. True. But currently, there are only 4 modules packages in sid, and apart from ALSA (which is stabilizing), they don't need frequent updates. > But what really makes it impossible for me is that if there is a build > problem in one of the modules, then the entire kernel-image has to be > delayed or the module dropped. If the module build problem is then > fixed, the entire kernel-image has to be rebuilt again. > > So IMHO, the cost outweighs the benefit for now. I strongly disagree here. Waiting the new kernel image for a week until a build problem is solved is nothing compared to the time between 2 kernel releases. And it is a worthwile loss if we don't have anymore issues with modules being out of sync. > In the long term, we should have as few binary module packages as > possible. They should either be integrated into our kernel-source > if it is popular enough or made source-only so that the people who > really need them can build them privately. I would see alsa in the > former category (it is already integrated into 2.5) and pcmcia-cs in > the latter (the built-in pcmcia works for most people). I wholeheartedly agree here. And that's exactly why all modules we provide should be provided as a patch for the kernel packages, one way or another. This would also be a good generic approach to separate some modules not needed everywhere, such as multimedia, usb, leading to smaller kernel packages. -- .''`. Josselin Mouette /\./\ : :' : [EMAIL PROTECTED] `. `' [EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
signature.asc
Description: PGP signature
