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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]