Kernel for Warty

[Matt Zimmerman]

So, the bad news is, the current kernel in Warty is not really what we want
for the preview release.  It has the following issues:

- Some unfixed security bugs

- Doesn't meet our hardware support goals (wireless drivers, etc.)

- Security updates are awkward ( (1 + 2*architectures) source packages need
  to be uploaded and built every time we do a kernel update, currently 7)

The good news is that we have a new 2.6.8.1 kernel package from Herbert Xu
which addresses these issues.  The further bad news is that we are very
close to our preview release date. :-/

The security bugs must be addressed regardless, and it would be extremely
helpful for supportability to have the security update issue addressed.
Those of us with currently-unsupported wireless cards would appreciate the
hardware support as well, and it's nearly zero-risk for those with
currently-supported hardware.  So, I'm leaning toward making an exception
for this.

The new packages use a different naming scheme (linux-* rather than
kernel-*), so they don't conflict with those currently in the archive, and
we should be able to switch between them without too much trouble if we run
into problems.

Issues with updating to the new kernel include:

- udebs.  Currently these kernels don't build udebs, but the existing
  linux-kernel-di/kernel-wedge stuff should work with only trivial changes.
  To be honest, I would very much prefer that we extend the linux-source
  package to build the udebs along with everything else, for the same reason
  that we want to build kernels for all architectures from a single source
  package.  This makes kernel updates much more sane, which is especially
  important for security updates.  Colin has expressed concern with this
  change, however, and so I am hesitant, but using linux-kernel-di means
  that we must do (1 + architectures) package updates per kernel update,
  rather than just one(!) if we build the udebs from linux-source

- Initial kernel installation.  I assume we would need to s/kernel-/linux-/
  in whichever d-i bit is responsible for installing the kernel.  Are there
  any other issues to consider here?

- module-source packages in universe might be broken, but they're generally
  crap anyway

- Anything else to consider?

-- 
 - mdz