Re: which kernel version for etch?
On Tue, May 09, 2006 at 11:46:32PM +0200, Frederik Schueler wrote:
> Fellow Debian kernel team members,
>
> let's take the recent "bits from the release team"[1] as an opportunity
> to start discussing which kernel version we, the Debian kernel team,
> want Etch to release with.
>
> In these "bits", the release team suggests we have a closer look on
> 2.6.16, which is very likely to get long-term support from upstream.
> To start with, please have a look at the threads starting with [2]
> and [3].
One side note, i read (don't remember where, maybe on slashdot) that (i
believe it was) andrew morton made a call for a version which is entirely
devoted to long-standing bug fixes (not sure if this would be 2.6.17 or 2.6.18
or if it would happen.
If this confir,s itself, i would argue that either all of it needs to be
ported to the 2.6.16.x branch, or that it could be a better candidate for us,
not sure though.
> Considering the current upstream 2.6 development model on one side,
> and Adrian Bunks intention to maintain 2.6.16.x for the next 2-3 years
> on the other side - backporting drivers and other updates like the 2.4
> line is handled -, makes the 2.6.16.x line an ideal candidate for the
> purpose of a release kernel for Etch.
Indeed, since we can benefit from the effort done by Andrew Bunk and all
others contributing to his effort, instead of doing it all oursevles.
The interesting question is what this means in term of stable kernel updates,
once etch is released.
Also, this makes it more urgent that we solve the out-of-tree-module issue,
since we would like to easily rebuild all modules for a given kernel, as well
as d-i, in order to be able to make abi-changing security updates to etch.
> One major issue is currently open for 2.6.16: ppc/PrEP support.
> Finding a solution for this is a show-stopper, if we want to go the
> 2.6.16.x path.
There is a solution for this, i don't like it much, but it will have to do,
unless another solution is found.
We simply need to use the ARCH=ppc tree for prep, which means creating a new
-prep flavour. I will do this in the next days / weeks. One advantage is that
we can try creating a kernel which is small enough to fit on a prep floppy
disk, like we did for the miboot floppies.
Naturally, we need to get the apus patches ported to 2.6.16 too.
> The second show-stopper is (IMHO) the missing sparc niagara support,
> which was added in 2.6.17-rc.
Can it be backported ?
> This has some implications, though:
>
> First, I would not like to have only a 2.6.16.x kernel in unstable for
> the time being until Etch is released, read until at least the end of
> this year.
>
> A possible solution could be:
>
> - branch the current linux-2.6 package into a new source package, say
> linux-2.6.16, tracking 2.6.16.x releases
Sounds the right thing to do for me. We keep linux-2.6 as trunk package, and
can branch off any number of kernel we want to have around long term, and mark
it as linux-2.6.<x>. Problem is with the metapackages, where will they come
from ? Bastian, can you comment on this ?
> - do the usual 2.6.x development in the existing linux-2.6 package,
> which probably should not migrate to testing until the release is
> done.
>
> Second, if we go this path and do an Etch release with 2.6.16.x,
> I would like to NOT stick forever with that very version we will have in
> testing at the day the freeze happens, but keep updating the kernel
> images and the installer for every point release to a reasonably newer
> 2.6.16.x upstream release.
> This would ensure more and new hardware support with every point release,
> avoiding one of the biggest drawbacks we currently have with the ancient
> 2.6.8 in Sarge.
I hearthily vote for this, and my effort to produce the .udebs from the common
kernel and get a solution for the out-of-tree modules where designed to allow
this easily enough, even in case of abi-changes. Support for those ideas have
been tentative at best, especially in the light of the extreme flamming i got
from the d-i folk about this.
> Security updates for Etch could just ship the latest 2.6.16.x release
> which fixes the respective issue, diminishing both the work needed to
> backport the fix and the time our users have to wait for it.
>
> Also, in order to add new minor releases to a stable 2.6.16.x package, we
> need to handle ABI changes in the stable kernel, which means rebuild and
> maybe patch all concerned third-party modules included in the release.
And d-i. And maybe klibc too, which is still built using the kernel headers.
We would also need to get some policy fixed about what happens to user
self-compiled modules in that case.
Thanks for taking the effort to raise this issue.
Friendly,
Sven Luther
Reply to: