On Fri, Nov 07, 2003 at 08:19:23PM +0100, Robert Millan wrote: > > [ Please keep CC to [EMAIL PROTECTED] ] > > 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
