Hi, On Sunday 29 January 2006 00:30, Holger Levsen wrote: > There are several reasons why 2.4 is still interesting: > - Kernel 2.6 is still a moving target... As Marco d'Itri pointed out, this will stay this way, so I'm confirmed, that some people will continue to want to use 2.4 instead :-p Seriously, I know more than one (professional ISP) setup, where people happily run recent 2.4 kernels and told me, they want to continue as long as possible... > * Unfortunatly, nobody from the kernel team is really interested in > working on 2.4 anymore. They do security fixes for the 2.4 kernels > in woody and sarge, for which I'm very thankful, but that's about it. > > Even though 2.4 is moving very slowly nowadays (mostly security > updates, very seldom new drivers are including), this is more work than > needed, because every fix needs to be backported to 2.4.27 (and 2.4.18 for > woody). Moritz Mühlenhoff wrote: "According to a linux-kernel posting by Marcelo Tosatti a few weeks ago 2.4 is now in strict maintenance mode, with only critical bug fixes being allowed." So I have the following idea regarding security support for 2.4 in etch: - make 2.6 the default for new installs but provide 2.4 for those who want it - issue a fat warning in the release notes, that security support for the 2.4 kernel packages will be special+different for etch: the 2.4-packages wont be updated, instead newer versions will be packaged, which will provide the upstream security fixes. (So instead of porting the changes from 2.4.34 to the 2.4.33 sources, we'll release a 2.4.34 package in stable-updates.) I'm curious to hear your opinions on that. (Another option would be to package 2.4.34 as 2.4.33, but I think this more ugly...) > - 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.) hhpa has dropped 2.4 support for sarge... s390 also doesnt seem sensible. On Tuesday 31 January 2006 03:50, Horms wrote: [...] > However, leading up to Etch, as we now are, I really feel that for the > various reasons you listed, the support burden of 2.4 in Etch is heavier > than its benefit. So, except for architectures that absolutely must have > it, we should drop 2.4. I believe 2.2 was in Sarge for some > architectures, and probably will also have it for Etch. So this idea is > by no means new. > > To be quite honest, when people like Ted T'so advise me that 2.4 isn't > really viable for Etch, I tend to take notice. > > If, the release maintainers decide that we really must keep 2.4, > then moving forward to 2.4.3X with the new unified packaging > that is seen in current linux-2.6 packages is the next best option. > Holger, I guess that responsibility would fall on your shoulders > for now, as I unfortunately do not have the time to devote to it. > Hopefully some more volunteers can be found. As said, I would try (and think I'll succeed), but when people advise me to ask others for advise, I usually listen :) So, release-managers please speak up on this issue. (The complete thread started at http://lists.debian.org/debian-kernel/2006/01/msg00742.html) As I see it, there is some cost and some benefit in having 2.4 in etch (and nobody is really able to tell which is higher). And the biggest problem (as in cost/work), would be security support, which IMO could be dealt with as described above (if the security team approves this exceptional handling), which would keep the amount of work required on a sane level. (And which I also volunteer to do/help with.) I dont wanna push this just because I want to maintain the 2.4 kernels (rather I want 2.4 kernels in etch because I prefer rock-solid kernel and systems.) IMHO some users would be happy about a official & uptodate 2.4 kernel in etch, "that's all". If my todo-lists were smaller, I would probably just work on that package, upload it (somewhere) and start a discussion then. But as I'm very busy, I want to know now, if this time is spent usefully, or if I rather should do something else. (I'm also aware that a new kernel package - with a different packaging then the one used (for 2.4.27) now - needs to be ready soon, so it can be properly tested and integrated.) regards, Holger
Attachment:
pgpi28it9Y7aT.pgp
Description: PGP signature