Re: Kernel 2.4 for etch or not
On Sun, Jan 29, 2006 at 12:30:04AM +0100, Holger Levsen wrote:
> - According to popcon, 6-7% of the i386 users have a kernel-2.4 image
> installed.
>
How much of those are using it out of pure inertai, ond how many really need
it ?
> * Of course there are some issues which need to be taken into consideration
> when thinking about whether it's worthwhile to have 2.4.3x in Etch:
>
> - it needs gcc-3.3 to compile, gcc-4.0 won't work. Period. So gcc-3.4 also
> needs to supported during etch's lifetime - which will be something like
> 2009 when etch+1 will become oldstable (by current release cycles)...
>
I can assure you thatsome kind of gcc-3 will be present in etch, we even carry
2.95.x right now.
> - it's not sensible to have powerpc and amd64 flavors, and probably
> others. So this kernel package will not be arch any. (Which is not
> really a problem, but unusual.)
powerpc upstream has abandoned 2.4 support (at least for the subarches we care
about) in early 2002 or 2003. The only subarch which still needs 2.4.27 is
nubus. i don't think the nubus patches have been ported to 2.4.32. And this is
another point which you need to remember, it is not only the main kernel, but
the forward porting of a huge amount of per-arch/subarch patches.
hppa dropped 2.4 support for sarge, and m68k has more stable 2.2 and 2.6
kernels if i remember well.
> - Both kernel 2.4 and 2.6 contain non-free firmware and drivers. I
> seriously doubt people want to deal with this issue and solve it for
> 2.4. For 2.6 it will be done, but for 2.4 ? As I see it, this is the
> biggest showstopper for 2.4 in etch, I would be happy to be proven
> wrong. As a starting point, you can look at this [1 investigation]
> by Bill Allombert about the the situation in 2.4.25.
I think it is sane to make an exception for 2.4 non-free firmware, if we go
from the assumption that it is a kernel which will be removed in the long run,
and we are doing the right thing for 2.6. If we need a GR for this, i guess it
will have no trouble passing. Should be separate from the generic 2.6 kernel
GR.
> Removing those files would be an option, but maybe we can also "borrow a
> better solution" from 2.6...?!
Just ignore this issue.
> - if 2.4.32 or .33 shall be used in d-i/g-i, work on this integration
> needs to be started real soon now.
>
> I have done some work on creating a linux-2.4.32 package which is based on
> the new kernel packaging. I got busy with videos for debconf-es2, so I
> didn't finish and commit this.
Well, i will stay silent about this, but you all know my opinion concerning
the d-i kernel .udeb situation.
> Horms made a [2 presentation] about the kernel packaging in debian for LCA
> and gave two options: a.) support and backport fixes for 2.4.27 or b.) go
> with 2.4.32. Somehow he did not consider the option of dropping 2.4 even
> if he calls it legacy ;-)
>
> Besides technical reasons (security fixes handled by upstream, some driver
> updates and very few new ones) I think we should not forget that most
> people have no idea that 2.4.27 in debian is far closer to 2.4.32 than to
> .27, and therefore will think debian ships an outdated 2.4 kernel. So I
> think we should simply go for 2.4.3x, if it is sensible to support 2.4 in
> etch at all.
We could ship 2.4.3x in a 2.4.27 named package :)
> It "just" needs to be done, and I volunteer to do it (with the help of the
> kernel team, the porters and anybody else who wants to join), if this work
> will not be in vain.
Yes, please go ahead, and make sure you commit your work to svn ASAP, so other
can help you out.
Friendly,
Sven Luther
Reply to: