Re: which kernel version for etch?
On Sat, May 13, 2006 at 12:44:36PM -0600, dann frazier wrote:
> On Sat, May 13, 2006 at 06:23:46AM +0200, Sven Luther wrote:
> > On Fri, May 12, 2006 at 05:08:34PM -0600, dann frazier wrote:
> > > On Fri, May 12, 2006 at 01:31:30PM +0200, Sven Luther wrote:
> > > > On Fri, May 12, 2006 at 09:40:37AM +0200, Bastian Blank wrote:
> > > > > On Thu, May 11, 2006 at 05:00:03PM -0600, dann frazier wrote:
> > > > > > I don't know what Bastian was intending; but the scenario I mentioned
> > > > > > was to:
> > > > > > 1) Upload linux-2.6.16 to sid w/o metapackages
> > > > > > 2) Let linux-2.6.16 migrate to sid
> > > > > 3) Upload linux-latest-2.6 via t-p-u
> > > > >
> > > > > > Either way, yes. We should remove linux-2.6 from testing once
> > > > > > linux-2.6.16 enters.
> > > > >
> > > > > Bastian
> > > >
> > > > I am not sure i like this, this means we separate the metapackages out of the
> > > > common package again. Is this a good thing ? We made the inverse step earlier.
> > >
> > > Yes, I'd rather see us keep the metapackages bundled in linux-2.6.16.
> > > The fewer packages that have to be updated for a security update, the
> > > better.
> > >
> > > Of course, I do see the benefit to Bastian's suggestion - we'd have
> > > working metapackages for both sid & etch that pull in the latest
> > > available in that dist. My proposal leaves sid meta packages pointing
> > > at the latest kernel for etch.
> >
> > Mmm. Do we really want the default for sid to be something that will maybe
> > never be going into etch ?
>
> I think so; there is a class of users (myself included) who want to
> run/test the latest and greatest on some machines, and its nice when
> it automatically updates. Users that just want to run what will go
> into testing should, well, just run testing :)
We could have special sid-only metapackages then. This would solve the issue
neatly.
We would have one package aimed at etch, which is the current linux-2.6 or
linux-2.6.16 or linux-2.6-etch or whatever, and exactly like current
linux-2.6.
And then we would have another package, aimed at unstable, and which is not
supposed to go into etch. This package would be named linux-2.6-dev or
something such, and have another set of metapackages, which would have the
same effect as the current ones, except they are named with some suffix which
clearly identicate them as the sid version, and will thus never be in
confusion with the real metapackages.
This would also help to avoid accidental upgrades to sid kernel from an etch
user trying to get one or another sid packages in a clumsy way.
Friendly,
Sven Luther
Reply to: