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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]