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: