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

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Fri, Nov 07, 2003 at 08:19:23PM +0100, Robert Millan wrote:
> [ Please keep CC to 219582@bugs.debian.org ]
> On Fri, Nov 07, 2003 at 11:57:28AM -0500, Michael Poole wrote:
> > 
> > Having options for the sake of having options is, frankly, a hideously
> > stupid design doctrine.  Whose life will this package make easier?  As
> > a user, I have never been confused by Debian's "normal" Linux kernel
> > packages.  What specific benefits would your proposed package offer?
> There are (at least) the following benefits:
>  - Easy understanding of the package. Developers looking at the package will
>    find every piece in the place Debian packages normaly put it. The binaries
>    are in .deb, pristine upstream sources are in .orig.tar.gz, the debian/ dir
>    is in .diff.gz
>    I could finaly work out where everything is, but the current situation is
>    confusing. In my apt database, there are 136 packages that match "kernel-*",
>    from which 19 are "kernel-image-*", 7 are "kernel-source-*", 14 are
>    "kernel-headers-*", and 70 are "kernel-patch-*".

You have not obsoleted any of the kernel patch packages.

>   - Handled by autobuilders, which means new versions are compiled automaticaly
>     for all Debian architectures. Normaly, users of non-i386 would have to
>     wait untill a maintainer for each port compiles it manualy for their CPU.
>     This is specialy important for security updates. Remember DSA-358 and
>     DSA-336, for which the security team had to build the Linux kernel manualy
>     for all our architectures, delaying the advisory?

Have you perhaps noticed that the kernels from every architecture build
from different source packages?  Why don't you spend a little time
working out why this is so, what the issues are with trying to do it
from one package, and why we don't do that already?

>  - Automatical major updates (the x in 2.x.y). When 2.6 is suitable to be
>    the default version, a simple change in -defaults package (ala gcc) would
>    enforce updating on all existing systems that use this method. This prevents
>    us from encountering ABI incompatibility problems, like this recent one in
>    Glibc:
>      #215010: Illegal instruction with 2.2 kernel
>    This is not unusual. IIRC, Woody's Glibc wasn't supported by Linux 2.0 (I
>    once tried an upgrade from Slink after the Woody release)

I fail to see how a bug in the 2.2 kernel, triggered by a recent glibc
update, dictates anything at all.  A substantial portion of Debian
users won't run the kernel we supply anyway, no matter how we choose to
supply it.

Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Reply to: