Re: which kernel version for etch?
On Thu, May 11, 2006 at 10:36:10PM +0200, Sven Luther wrote:
> On Thu, May 11, 2006 at 01:39:23PM -0600, dann frazier wrote:
> > On Wed, May 10, 2006 at 11:02:29AM +0200, Sven Luther wrote:
> > > On Wed, May 10, 2006 at 10:15:45AM +0200, Bastian Blank wrote:
> > > > On Wed, May 10, 2006 at 07:46:12AM +0200, Sven Luther wrote:
> > > > > > - branch the current linux-2.6 package into a new source package, say
> > > > > > linux-2.6.16, tracking 2.6.16.x releases
> > > > > Sounds the right thing to do for me. We keep linux-2.6 as trunk package, and
> > > > > can branch off any number of kernel we want to have around long term, and mark
> > > > > it as linux-2.6.<x>. Problem is with the metapackages, where will they come
> > > > > from ? Bastian, can you comment on this ?
> > > >
> > > > Currently they are built from linux-2.6. This needs to be changed for
> > > > such a package. And after that, they need to be reintroduced through
> > > > t-p-u.
> > >
> > > Well, this means thought that they will no more be built with linux-2.6, right
> > > ?
> > >
> > > Why do you need to involve t-p-u, the current version in testing points to the
> > > linux-2.6 2.6.16-<something> which is compatible with the new packages. We
> > > just upload linux-2.6.16 to unstable and linux-2.6 without the metapackages,
> > > and they should migrate to testing normally or with an RM hint at the right
> > > moment, no ?
> >
> > The problem Bastian maybe seeing is that we cannot have the same binary
> > package (e.g., linux-image-2.6-686) provided by two different source
> > packages in a single dist.
> >
> > So, we'd need to remove them from linux-2.6.16 till linux-2.6.16 hits testing,
> > drop linux-2.6.16 from sid, then re-add via t-p-u.
>
> Euh, ok, but i was thinking of uploading a new linux-2.6 package without those
> metapackages to unstable, and then upload linux-2.6.16 to unstable with them.
Sounds like that would work, but sid users would be stuck on 2.6.16
for automatic upgrades until etch ships in that scenario - which is
what we did in sarge, and seemed to work ok. That way we could
continue to pump in 2.6.16 kernels via sid instead of using t-p-u and
losing potential testing.
> When the migration happens, the metapackages in testing which where previously
> owned by linux-2.6, will now become owned by linux-2.6.16. This will cause
> problem, but a proper hint by the RMs should probably solve the issue.
>
> I think i understand now, Bastian was intenting to upload linux-2.6 to
> testing-proposed-updates without the metapackages ?
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) Drop linux-2.6.16 from sid, leave it only in etch
4) Update linux-2.6.16 in etch w/ metapackage support
5) Maintain linux-2.6.16 via t-p-u
I prefer not to do that though; I'd rather see us leave linux-2.6.16 in sid
with metapackages and drop the metapackages from linux-2.6 until etch
releases. That way we get pre-etch user testing and can have more
direct control over the testing migration.
> I guess at that point, we should simply remove the linux-2.6 package from
> testing.
Either way, yes. We should remove linux-2.6 from testing once
linux-2.6.16 enters.
--
dann frazier
Reply to: