Re: more current kernels for sarge in volatile?
On Thu, Dec 29, 2005 at 01:29:13PM +0100, Frans Pop wrote:
> On Thursday 29 December 2005 13:04, Sven Luther wrote:
> > To add to that the fact that with a minimal rebuild of support tools
> > (yaird and backported udev for me), the etch/sid/experimental kernels
> > install just fine on a sarge system. I run all my sarge systems like
> > this, and it works just fine.
>
> Problem is that the upgrade of a system to a new udev is _not_ trivial and
> those kind of problems are not something users expect when upgrading a
> stable release, even if from volatile.
Indeed. Like said, Andres mentioned that latest kernels run fine with the udev
in sarge, it is just the reverse (older kernel with newer udev) which seems to
have problem, but YMMV.
And as said, given the devfs deprecation, a new kernel means moving to either
yaird or initramfs-tools, none of those being trivial right now, so what do
you want.
> It is a different thing if a user chooses to upgrade himself using
> unofficial backports (even if they are provided by the kernel team).
>
> Also, using 2.6.12/14/15 in Sarge (volatile) IMO means that the kernel
> team will need to commit to maintaining that version with regard to
> security updates, just as for 2.6.8.
Nope, and that is exactly the point, the volatile kernel will follow the etch
kernel closely, and so security updates will be done for both in one stroke.
> Continuously making the latest kernel available for Sarge through volatile
> IMO is not an option, unless maybe done through a separate repository
I would like to hear a more advanced explanation of why this is not an option
? It does fit well with the definition of volatile (that which changes often)
as i understand it.
> kernel-volatile with all due warnings of "use at your own risk" attached.
Which is why i propose to mirror the etch kernel and not the sid one. Since
etch is supposed to be release quality, and furthermore we have to guarantee
the sarge to etch upgrade path, it should be ok.
> I think the whole issue of introducing a new kernel in Sarge is being
> hopelessly underestimated here.
Well, i don't say it makes sense, i just say, and i think all the kernel team
will agree with me on that, that unless someone else provides manpower to
maintain such a (yet another that is) fork of the kernel tree, the kernel team
is not interested in it unless it mirrors closely one of our main kernels.
Things would be different if this kernel where aimed at
sarge-proposed-updates, which would mean we could retire 2.6.8 :)
Friendly,
Sven Luther
Reply to: