Addition of Newer Kernel @ etch & 1/2

[dann frazier <dannf@debian.org>]

hey,
  I've had discussions with a number of folks at DebConf this week
about how we might add new hardware support to a stable release after
its first release.  The most well-received suggestion has been to add
an additional updated kernel in a stable point release - perhaps near
the middle of the release's scheduled lifespan, or when some milestone
in upstream kernel development occurs.  Members of the stable release,
stable security and d-i teams all appeared to be quite open to this
discussion.

For example, if we shipped etch with 2.6.15 today, we could later add
*optional* 2.6.20 package backports into official stable.  d-i would
need to be updated with this kernel of course, and we wouldn't want to
change the default behavior for current stable users by making the new
kernel the default.  Instead, it could be a new boot-time selection
(like 2.6 currently is for sarge/i386).

Of course, this means maintaining security support for an additional
kernel; however, doing so in etch would still be an improvement over
sarge & woody.  Instead of shipping both a recent and an old kernel
on day 0, we would ship a recent kernel on day 0 and an even more
recent kernel a number of months later.

If we want to prepare for this possibility, the one issue that the d-i
folks pointed out is that we'd probably want to refactor our meta
packages such that we could have both metapackages for the latest
2.6.N and additional packages for the latest 2.6.N+, so users can
track whichever they prefer.  One suggestion was to use
linux-image-etch-foo for tracking 2.6.N and something like
linux-image-etch+-foo for tracking the 2.6.N+ update.

Note that this is in the context of etch instead of sarge because
there are a number of transitions that make such an update quite
difficult in sarge (devfs removal, udev, initramfs transition,
linux-2.6 transition, etc).

-- 
dann frazier