On Wednesday 17 May 2006 22:12, Thiemo Seufer wrote: > It will AFAICS break all remaining d-i with 2.4 because those try to > install a 2.4 kernel from testing by default.
Yes, installs will break to some degree. If no 2.4 kernel is available, d-i will display a list of other available kernels (probably 2.6). However, crossinstalling kernel versions (i.e. installing running 2.4 setting up target with 2.6) is not really supported. It will probably lead to errors and at least some packages incorrectly installed or missing. Full CD installs are of course not affected. IMO the question whether 2.4 should be removed now and if so for which architectures is something to be decided between the kernel team and porters. If a porter needs more time to switch to 2.6 for the installer, he should probably come up with a migration plan and timeline. Purely from a d-i release management point of view, it would be nice if the removal of 2.4 could be delayed until just after the next beta release. The release date for that depends on the progress of AMD64 archive migration (it is not yet installable from testing). Full CD installations using that release could then still install 2.4 and we could set completing switches to 2.6 as the main goal for d-i Etch RC1. I could also understand if m68k would keep a 2.4 kernel for a while longer. As it is not a release arch, it might be acceptable for release managers to keep a m68k 2.4 kernel in testing/unstable. 2.2 should probably be dropped completely. Whether we will be able to keep 2.4 support in d-i if all other architectures have dropped it is uncertain though [1]. Cheers, FJP [1] This depends mainly on changes needed to support persistent device naming in d-i which is very much needed for Etch.
pgpizERxY1ONi.pgp
Description: PGP signature