Re: Getting newer kernels into stable
Andrew Pollock wrote:
> I realise there are issues with adding and removing kernels into stable, as
> the security maintenance goes up, and I'd like to hear what the security
> team has to say about that. Or perhaps newer kernels should go into
> stable-proposed-updates? This doesn't really address the installation issues
> that people have with newer hardware though.
New kernels for stable are a no-go except for very few exceptions.
If you want to provide updated kernel packages for Debian stable,
that's fine and I appreciate it, but please create a repository on
<http://people.debian.org/~apollock/kernel/> or similar.
Updating kernel images in Debian stable affects more than we may think
about in the first place, such as:
. tons of modules packages that would have to be updated as well
. tons of patch packages that won't work with newer kernels
. modules packages won't work with a modified ABI
. additional kernel packages hurt the security team support-wise
. additional kernel packages break debian-cd creation
. new kernel packages imply that old packages have to go
. new kernel packages can introduce new cans of worms
. potential problems with the installer
Hence, I am not convinced at all that new kernel packages are suited
for Debian stable. However I would love somebody to maintain a
repository of (security fixed, of course) kernels for Debian stable so
those users who would like to use them, are free to do so. Such a
location should be documented in the Release Notes.
> Is it feasable for subsequent point releases of stable to ship with newer
> kernels by default, and security support for earlier kernels to be
> discontinued at point release time?
Please explain the "by default" part. For woody/i386 one default is
2.2.22 and another default is 2.4.18, whereas the default is installed
from boot-floppies and not from kernel-image packages.
> for example, let's say hypothetically, Sarge shipped with 2.6.4, and then 3
> months later, Sarge_r1 ships with 2.6.6 as the default kernel, and a month
> later, a vulnerability is found in 2.6.4, that isn't in 2.6.6. Would we need
> to issue a patched 2.6.4 if we were already providing a non-vulnerable 2.6.6
> in a newer point release of stable?
Yes.
> I think the kernel is probably the single biggest package that really dates
> a stable release (sure, there's lots of other "perishable" packages like
> spamassassin and snort, for example), but if you can't install the stable
> release because the kernel it uses can't find your hardware, then you're
> really behind the eightball from the word go.
If you can't insatll the stable release because the kernel was updated
and the new version doesn't work as expected, you're doomed as well.
As I stated above, I'd love to see a repository of updated packages,
just keep them aside but visible.
> Joey, as SRM, what do you think? Is the installability of stable releases on
> modern hardware something you think is significant? Is there some sort of
> compromise that can be arrived at for the handling of newer kernels in
> stable?
It is significant, but updating the kernel is still not the path to take.
Regards,
Joey
--
A mathematician is a machine for converting coffee into theorems. Paul Erdös
Please always Cc to me when replying to me on the lists.
Reply to: