[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Kernel 2.4 for etch or not


  * This is a blog entry I wanted to write for about six weeks now, but I 
    was busy with other stuff. In December 2005 I got curious why 2.4.32
    wasn't packaged for Debian and investigated the situation a bit.

    There are several reasons why 2.4 is still interesting:

    - Kernel 2.6 is still a moving target...

    - Some hardware is only supported with 2.4, for example older laptops
      which need APM and don't work with ACPI. Also some non-i386 machines.

    - According to popcon, 6-7% of the i386 users have a kernel-2.4 image

  * 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).

  * 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)...

    - 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.)

    - 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.

      Removing those files would be an option, but maybe we can also "borrow a
      better solution" from 2.6...?!
    - 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.

    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.   

    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.

    Please send comments to the [3 debian-kernel-mailinglist], where I posted 
    this blog entry before. Thanks.


  [1] http://lists.debian.org/debian-legal/2004/04/msg00074.html
  [2] http://www.vergenet.net/linux/debian_kernel/

Attachment: pgpD0zicuuDpg.pgp
Description: PGP signature

Reply to: