Re: which kernel version for etch?
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 ?
> At minimum I want to make sure linux-latest-2.6 is a single source
> packages - not per-arch. Building all of these packages for sarge
> abi-changing updates sucks.
Indeed. Notice that i said so in early 2005 and was mostly ignored or bashed
for it.
A two package (or maybe three package, with another one providing the .udebs),
would be a solution.
Andreas, here is an idea for you :
The current mess that is the kernel .udebs packages could partially be solved
if d-i restored the common packages for all arches. This would not be as good
as having them in the main kernel package, but also not suffer the problem of
having to rebuild the kernel for each minor d-i change. Altough this latest
point is probably not so good, as we rebuild the kernel package more often
than the .udebs are modified anyway.
Andreas, will you provide a log or summary of the decisions taken at that
debconf meeting ? Will it be possible for outsiders to participate remotely in
that discussions ?
Friendly,
Sven Luther
Reply to: