Re: renaming linux-kernel source package
dann frazier <firstname.lastname@example.org> writes:
> 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
> We are at least pretending that's the case, because we do not plan to
> ever have multiple 2.6 kernels in a single stable release. If there's a
> bug in the kernel we're currently trying to stablize, then it needs to
> be fixed in that version.
> Note that one side-effect of dropping the minor number in the source
> package name is that we won't be able to have one kernel in sid and one
> in testing and be able to use sid as an update path. For example,
> consider the way we had 2.6.10 in sid and 2.6.8 in testing late in
> sarge. This allowed us to get some testing on a kernel and make a more
> informed decision about which one we froze on for sarge. We can of
> course use experimental for this, but we can't expect to get much
> testing w/ experimental.
Why not? Both testing and sid can have different versions of
kernel-source-2.6 without problems. One just havs to report a RC bug
against kernel-source-2.6 in sid to prevent it entering testing.