Re: kernel-{image,headers} package bloat

[Adam Heath <doogie@debian.org>]

The old way, we had one kernel, optimized for the lowest denonimation of ia32
machine.  Ie, i386.  We then modified the drivers that were compiled into the
kernel.

Now, using an initrd, we no longer need to compile different variations of
drivers and modules into and out of the kernel.  We can compile almost
everything as a module, and use the initrd to insert the required drivers at
boot time.

Everyone agrees that using an initrd, allows us to reduce the number of kernel
images, and thereby, reduce the load on mirrors, cds, and boot floppy workers.
However, by increasing the number of kernel images(which specific cpu
optimization does), will not help them in any regard.

This supposed initrd, that contains the modules to be inserted, has to have
modules that match the kernel being booted.  This means they have to be
optimized for the same type of cpu.  To continue further, this means we can't
use a generic initrd, but one that is either created dynamically, at
installation time, built from the generic base initrd, and the specific set of
matching modules, or, use a prebuilt one, that matches the particular kernel
that has been choosen.

Now, it doesn't take a genius, to see how this will cascade.  For each
optimization of a kernel, there will be a full kernel-image.deb.  Then, for
the boot disks, there will be the individual kernel, and the modules to match
it(this is a doubling of space).  So, for all the numbers given in this
thread(whatever their value), you have to double them.

Now, my gut instinct says that, as of this moment in time, no one has
addressed the building of this initrd, to use at boot time, AFTER
installation.  Yes, we may have an installation initrd, but, in almost all
circles, that is going to be different that what is used after the system is
installed.  Has this boot time initrd been constructed?  Do we know how we are
going to do that?

The best way to handle all this, is to train users how to compile a kernel,
or, let them pick the optimization they want, and we compile the kernel for
them.  We could even use a double boot technique, to make sure it works.  The
new kernel is installed, added to lilo, but not made the default.  System
reboots, and the user picks the new kernel.  IF the kernel works, we switch
the default.