Re: Bug#331391: Re: ftpmaster: Please remove 2.6.8 kernel images
On Fri, Oct 14, 2005 at 07:35:46AM +0200, Sven Luther wrote:
> On Fri, Oct 14, 2005 at 11:04:16AM +0900, Horms wrote:
> > 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.
>
> Yep, but we promised our users only the release-to-release upgrade path.
Ok, understood.
> > > > 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?
>
> It is because the -header packages should be used only for modules build, and
> any other use (like building klibc like maks tried to do), should be actively
> discouraged, and for debian third party module packages, they should move to
> the new packaging name, thus fixing the upgrade problem on their side, and for
> non-debian-packaged third party modules, i would rather everyone reread the
> module compilation instructions (once we have wrotten them) and redesign their
> module builds accordyingly. We didn't promise to support those anyway.
>
> So, i think not only dropping the kernel-headers backward compatibility
> modules will hurt nobody, but it is also a feature :)
Thanks, I think that is pretty reasonable. We can always add it
a bit later if it turns out to be a problem.
Jeroen, can you please go and remove the packages as originally
requested?
--
Horms
Reply to: