Sorry for not really responding to this earlier. I've been somewhat distracted by the GR nonsense going on...
I saw the conversation with Joey on IRC yesterday, and I think my comments below are in line with that. On Sunday 24 September 2006 19:04, Max Vozeler wrote: > Some possible approaches have come out of discussions during the > last months - I've tried to summarize them below. All of them > have their own advantages and disadvantages. I'm interested what > you think and any aspects you see that I've not considered. > > Approach 1: Building module udebs in linux-kernel-di-* > Approach 2: Building module udebs in linux-modules-di-* > Approach 3: Building module udebs in <module>-modules-di-* I think I like 2 best. > Approach 2: Building module udebs in linux-modules-di-* > ------------------------------------------------------- > > Mostly like the above, but creates a new package for each > architecture that builds module udebs. It could be used for > more than one out-of-tree module if the need arises. > > Advantages: > - No delay before kernel can be updated; The package could be > uploaded later. In the in between time (for arches that have already switched to the new kernel), part of the functionality of the installer will be unavailable. Seems acceptable though. > Disavantages: > - Update to newer kernel requires another package to be updated Acceptable. > - More work for port maintainers (?) Not necessarily. As there is no need to run depmod, I would say it should be fairly straightforward to let the autobuilders take care of that. And even if not, I've already got the basic script to do the builds of linux-kernel-di-* centrally; it should be straightforward to have that support linux-modules-di-* too. Cheers, FJP
pgprL7BQrph20.pgp
Description: PGP signature
