Re: more current kernels for sarge in volatile?
On Thu, Dec 29, 2005 at 12:15:53PM +0100, Andreas Barth wrote:
> Hi,
>
> * Sven Luther (sven.luther@wanadoo.fr) [051229 11:47]:
> > The main problem are the too strict rules for building in volatile, which stop
> > us from uploading the etch/sid kernels and associated packages to it.
>
> Actually, I think we should first consider which kernel minor version we
> want to use (including of course the requirements on the user side like
> udev, devfs, ...), and if we have done that, resolve any technical
> issues with the infrastructure.
Obviously, from a kernel maintainer perpespective, the one that makes more
sense is the latest one we are working on, which will always be the more
actively maintained one and as a consequence the one of more interest to the
users, not to mention the fact that for the users to have any benefit, they
need the latest kernel, not really one which is newer than the sarge one, but
still a couple of month old.
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.
> The basic issues are the same wherever this happens:
> - Users should get a working upgrade path from sarge to
> sarge-newer-kernels and from there to etch. This needs to be true for
> the kernel and all tools included, which means we should try to limit
> the number of changed tools as much as possible.
If it is the same kernel as etch, it is obviously trivially true :)
> - Any security issues that happen need to be resolved - so we should
> limit the number of versions we offer.
Indeed, so the best is to have it be identic to either the etch or the sid
kernel (or preferably both). They in fact don't even need to be rebuilt as far
as i can tell, which makes offering them to users rather trivial, provided the
support packages are there.
Friendly,
Sven Luther
Reply to: