Let's have udeb's for each single module ...

[Sven Luther <sven.luther@wanadoo.fr>]

On Thu, Jul 28, 2005 at 12:07:44PM +0100, Colin Watson wrote:
> On Tue, Jul 26, 2005 at 03:26:04PM +0200, Goswin von Brederlow wrote:
> > The problem is that the DAK will update linux-2.6, kernel-tree-x.y.z-n
> > and kernel-image packages without any regards to linux-kernel-di. They
> > will become out of sync and end up without source -> GPL violation.
> 
> Last I checked, dak was being reeducated so that it could be told about
> udebs it needed to keep around due to them being in initrd builds. The
> same approach could be used fairly easily to keep kernel source around
> until the corresponding udebs have been rebuilt.
> 
> The main problem with moving udebs into the kernel build process, I
> think, is that the installer team needs to be able to change their
> structure relatively frequently; for example, the exact balance of
> modules in various udebs affects whether it's possible to build
> installer floppies and other media with space restrictions.
> Historically, having the udebs be controlled by the d-i team made sense.

This goes away by having single .udeb per module, and a .udeb dependency tree
generated by or in the same way as the depmod stuff.

Is it really all that much complicated to teach the infrastructure to handle
bigger number of .udeb packages, than doing loads of hacky workaround like the
above ?

Friendly,

Sven Luther