On Sun, May 25, 2003 at 07:33:04PM +1000, Herbert Xu wrote:
> Anthony Towns <aj@azure.humbug.org.au> 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 <aj@humbug.org.au> <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!''
Attachment:
pgpHUZBVLuS6L.pgp
Description: PGP signature