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

Re: renaming linux-kernel source package

GOTO Masanori writes...

> At Mon, 11 Jul 2005 02:08:51 +0300,
> Andres Salomon wrote:
> > This is the source package only, not the binary (image) package; so, if
> > users have a working kernel installed, they will be able to upgrade,
> > test out the new kernel, and use the old one if the new one is broken.
> > If we upload a new kernel that is broken, and it replaces the old one,
> > it will still only be in unstable (as long as someone files an RC bug.
> > Experience has shown that people are not shy about filing RC bugs when
> > we break their machine horribly ;)
> Thanks for your explanation, I was confused the difference between
> source package and binary package.  Yes, your idea is definitely good
> idea for me.

I still see the issue that GOTO brought up as a problem. There is no "one size 
fits all" 2.6 kernel version, there's just too many drivers and too many 
changes. I don't think users should be expected to rely on a binary 
kernel-image only available if they've already installed it(or have to get it 
from snapshot.debian.net).  What about a user who relies on an older binary 
kernel-image and loses a hard drive and wants to reinstall? Or someone with a 
bunch of particular identical systems that need a non-latest kernel? For 
example I have a PC that uses an SiS chipset that doesn't work at all with the 
2.6.8 kernel in sarge due to it's sucky USB stack.

I really like the proposal other than that, but is there a way to keep a 
limited set of older stuff around longer? Sort of analogous to the "oldlibs" 
idea.  Maybe the package can split off older versions of itself, with more 
descriptive names, as it moves forward. Or something like that...

Matt Taggart

Reply to: