On Mon, 2005-07-11 at 01:53 -0700, Matt Taggart wrote: > 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. > One of the things I like about sarge is the ability to install 2.4 or 2.6 kernels. I prefer the new kernel development model, but this does mean that we're only going to have a 2.6 kernel. This is fine when everything works, but when there's breakage within a specific driver, it's invaluable (especially during install) to be able to fall back to an older kernel. This is something we should probably discuss with the security team. On one hand, it would be useful to have an older kernel to fall back on. On the other, it's almost twice as much work work to maintain security fixes for an older kernel. > 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... > Thiemo's concerns lead me to believe that perhaps we should track two kernels at all times, assuming the security team agrees. The two source packages could be called linux-2.6 and linux-2.6-new, where linux-2.6 might contain 2.6.12 images, built for all architectures, and linux-2.6-new might contain 2.6.14 images that we're currently attempting to build for all archs. While 2.6.14 is the latest and greatest from upstream, we could try to get it in a state that's preferrable for all archs; if we achieve that, update linux-2.6 to use 2.6.14. If 2.6.15 comes out in the meantime, then release linux-2.6-new with that, and attempt to get all archs happy with that kernel. This is a similar strategy to testing, except instead of things happening automatically, we're trying to manually control it. Keeping a space of several versions between linux-2.6 and linux-2.6-new will mean that when it comes time to release etch, users will hopefully have the ability to select between two significantly different kernels during install. -- Andres Salomon <dilinger@debian.org>
Attachment:
signature.asc
Description: This is a digitally signed message part