Re: more current kernels for sarge in volatile?
On Thu, Dec 29, 2005 at 01:11:40PM +0100, Andreas Barth wrote:
> * Sven Luther (sven.luther@wanadoo.fr) [051229 13:05]:
> > On Thu, Dec 29, 2005 at 12:15:53PM +0100, Andreas Barth wrote:
> > > * 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.
>
> Well, if this is going to be the other stable kernel for sarge, it will
> be old and not actively maintained anyways soon enough between now and
> archival of etch. So, the basic question is more: Where are we better
> off with tools?
we are better of if the kernel team can concentrate on one kernel only,
instead of dealing with loads of it. I would think it is best to propose both
the etch and the sid kernel to sarge users, together with the tools.
> > > 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 :)
>
> I don't fear with the kernel, but I fear with the backported tool set.
> Development is not yet frozen, and it might happen that not all
> intermediate versions in etch are supported for the final version in
> etch.
Ah, well, not much can be done there. Well. I run with an older trivially
backported udev found on my people.debian.org page, and a simple rebuild of
yaird. This may be the best solution, with the obvious problems concerning the
use of yaird (no install from 2.4 kernels).
> > > - 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.
>
> Well, if we want to keep the minor number in volatile, than either
> kernel development has to be stalled (which is perhaps a not too good
> idea), or the kernels will be different soon enough.
Ah, you want to spawn another kernel tree for volatile, i think none of the
kernel will appreciate this. The idea of volatile is that it can evolve, so
after we have uploaded and tested the sid kernels (or once they move to etch,
which will be faster once the yaird|initramfs-tools problems are solved) we
can upload it to volatile or something.
Indeed, i think the best idea is to simply upload the whole set of etch tools
(kernel-package, udev, yaird, possibly initramfs-tools), either into volatile,
or better yet into a separate kernel.volatile or whatver subarchive, and
rebuild this inside of sarge+this pool. By going with the etch version we
guarantee there is some testing and the version is fine, and we guarantee the
sarge->etch upgrade path.
Well, the sole sore point here being udev, all other tools are part of the
kernel umbrella (yes, Manoj, even k-p :), and should be trivial to handle,
while udev has an agenda on its own, so your testing->etch upgrade path
concerns are warranted for this one. I think Andres mentioned that newer
kernels working with older udev is ok though, so maybe we can skip this one ?
Friendly,
Sven Luther
Reply to: