Re: Bug#331391: Re: ftpmaster: Please remove 2.6.8 kernel images

[Horms <horms@verge.net.au>]

On Thu, Oct 13, 2005 at 03:01:09PM +0200, Sven Luther wrote:
> On Thu, Oct 13, 2005 at 09:40:46PM +0900, Horms wrote:
> > On Thu, Oct 13, 2005 at 12:57:49PM +0200, Sven Luther wrote:
> > > On Thu, Oct 13, 2005 at 08:04:01PM +0900, Horms wrote:
> > > > On Wed, Oct 12, 2005 at 09:38:42PM +0200, Sven Luther wrote:
> > > > > Also, if the user don't upgrade those, nothing major will break, apart from
> > > > > the fact that he has a few unused bits on his harddisk.
> > > > > 
> > > > > So, i vote for simply removing them, and provide some notice of the fact and
> > > > > the new module build model in the release notes or something.
> > > > 
> > > > Its an upgrade problem, but it doesn't affect that many users
> > > > (I guess). I'm happy with your idea as long as you've considered 
> > > > the upgrade problem.
> > > 
> > > Iti s an sarge -> etch upgrade problem if anything, let's remove them for now,
> > > and once we sorted out the module build issues, we can always readd them fori
> > > etch if really needed.
> > 
> > What other type of upgrade issue is there?
> 
> etch->sid, etch->etch, sid->sid, random experimental snapshot or
> self-built->etch/sid :)

Ok, if you look at it that way, then given that
kernel-headers-2.6-<flavour> currently exist in 
sarge, etch, sid and not experimental, then
the current paths are already broken.

sarge->experimental
etch->experimental
sid->experimental

And if we remove the packages from sid and thus etch, then
the following paths will become broken.

sarge->etch
sarge->sid
etch->etch *
etch->sid
sid->sid *

* I say things like etch->etch, because if you have this
  weeks etch, and have kernel-headers-2.6-<flavour> installed,
  and we remove the packages, then you won't end up with
  anything to replace kernel-headers-2.6-<flavour> as one
  might expect.

> > If its going to be a problem for etch we may as well cope with
> > it sooner or latter, it really seems to be a no brainer of
> > handling kernel-headers-2.6-<flavour> the wway we alreaday handle
> > kernel-image-2.6-<flavour>
> 
> I would rather we drop it though.

Understood. I'm certainly warm to this idea from a simplicity point
of view. Though could you explain why you aren't worried
about the upgrade breakage? Is it because you don't think
many people are affected? Is it because it will just break
local builds, and not actually the bootability of the system?

-- 
Horms