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