On Sun, May 25, 2003 at 07:33:04PM +1000, Herbert Xu wrote: > Anthony Towns <email@example.com> wrote: > > Having kernel modules associated with the kernel source package they're > > built for makes it a bunch easier to make sure they're deleted from > > the archive along with the corresponding kernel images, and makes sure > > that when someone uploads a new kernel image, new module images get > > uploaded too. > 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. Is that really that big a problem? In unstable for i386, eg, we have pcmcia-modules packages for 2.2.20 (reiser and udma100-ext3), 2.2.25 (vanilla, compact and idepci) and 2.4.18-bf2.4. For alsa-modules we have seven flavours for 2.4.20-1. 2.4.20-3 seems entirely unsupported. > 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. Well, what we have now seems to be that the modules are all dropped everytime a new kernel is uploaded. :-/ > 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). As far as I could tell, we don't have any other examples at present, than alsa and pcmcia. Cheers, aj -- Anthony Towns <firstname.lastname@example.org> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!''
Description: PGP signature