Charles Plessy wrote: > How about releasing a RC1.5, then, with a 2.6.18 as similar as possible > as the one forecasted in testing ? Etch d-i installs etch; without forcing such a release to install unstable, it would not be possible to use the 2.6.18 kernel currently in unstable. If we point d-i at unstable, its prone to break all the time, since unstable is, well, unstable. An installer that installs unstable is also not a very valid etch "release candidate". There are of course all kinds of ways to hack around this, but all of them are suboptimal. For example, we could produce a hacked CD that includes unstable's kernel. And updated version of everything it depends on. And everything those dependencies depend on. But this would only work for systems installed from CD. We could add a special apt repository only for the kernel and stuff, but then we could have to have a separate gpg key for that repository hacked into the installer as well. Setting this up would take significant developer time, and that would be time that does not in the end benefit the etch release at all. In the end we would have to reverse all these changes and throw away all that work to get an installer that is suitable for release with etch. The best fix is to get the 2.6.18 kernel into testing. -- see shy jo
Attachment:
signature.asc
Description: Digital signature