On Wed, Dec 12, 2007 at 10:20:45PM +0100, Frans Pop wrote: > 1) A new version of the Etch installer with support for both kernels > -------------------------------------------------------------------- > This option would IMNSHO be insanity. > > First, I doubt people who are able and will want to work on the D-I side of > it can be found. > > Second, it would require having D-I initrds + kernel udebs + kernel packages > for 2 kernel versions on CDs meaning that netinst images would grow beyond > reasonable size and that an unacceptable number of other packages would get > pushed off the first full CD and DVD which would result in a significantly > reduced installation experience, mainly for the desktop task. > > > 2) Creating a second Etch installer based on the new kernel > ----------------------------------------------------------- > This is about on the same insanity level. > > It would also require extra work by FTP-masters because we'd somehow need > two separate D-I builds (sources, deb and images) in stable and on the > mirrors at the same time. > The only realistic option would be keeping the second installer outside the > archive, but that has its own disadvantages (chain of trust). > > And again I don't know who'd do the D-I work on it.
Not saying its a good idea, but what would be the issues with creating additional flavors of select etch installers builds? e.g., netboot/netboot+, netinst/netinst+, etc. > > 3) Using the Lenny installer to install Etch > -------------------------------------------- > This would be the easiest option. > > It is realistic for the following reasons: > - D-I is basically a mature product; a lot would have to go completely > wrong to have Lenny D-I releases that are not generally usable > - this has already been proven with Etch and D-I has only gotten more > stable; of course there will be a few errata, but there should be > nothing major; a lot of issues in betas have to do with _testing_ as > a suite and not with D-I > > The supported installation methods would be limited: no netinst CD or full > CD. What makes these two methods problematic? > For all other methods the user would have two options: > - run installation in expert mode or at medium priority; (s)he will then > be asked what suite to install and what kernel to install > - boot the installer with: > suite=stable base-installer/kernel/image=linux-image-2.6.24-x-$flavor > (or use 'suite=etch'); basically we tell the user to specify the actual > kernel instead of the default meta package; we can easily (and probably > should anyway) add an alias 'kernel' instead of the cumbersome parameter > 'base-installer/kernel/image' > > Of course you would need at least a Lenny beta 1 D-I release for this. > > Disadvantages (mainly netboot, not for businesscard and hd-media images): > - when a new Lenny D-I release is prepared, the old one can temporarily > be broken > - with later Lenny D-I releases the kernel used in the Lenny installer > could become newer than the etch+1/2 one > - if there were to be major changes at some point, supporting stable > installs could become harder or even impossible I would say an additional disadvantage is the complexity; these boot options seem pretty straightforward (esp if the "kernel" alias is added), but we lose the benefit of "just working". > 4) Option 3 + creating selected CD images based on the Lenny installer > ---------------------------------------------------------------------- > This would mainly depend on available debian-cd mirror capacity. > > This option is mostly relevant for netinst CDs and full CD/DVDs and > partially for businesscard CDs. It does not change 3) for netboot. > > It is relatively trivial to create CD images using packages from stable but > D-I from testing. I'd suggest not building full CD sets, but just the first > or first few images in a set. > > By including _only_ the new kernel packages on the CDs and omitting any meta > packages, the installer would automatically install the correct > kernel. I think I could use some clarification here. If there are metapackages for both etch and etch 1/2 kernels available (e.g. linux-image-2.6-686 and linux-image-2.6-23-686), would this prevent the installer from selecting the correct metapackage? Default metapackages are certainly something I'd like to see kept, to avoid the no-auto-upgrade problem we had w/ kernel abi changes in sarge. > For some architectures it should be possible to modify the default boot > parameters on the images so that the 'suite=etch' option is included by > default (with 'suite?=etch' the user would even still be prompted at lower > priorities). Which would solve the complexity issue I see w/ 3) > The disadvantages listed for 3) do _not_ apply to CD images as they are > self-contained and thus are not affected by changes in the Lenny archive. Thanks a lot for the analysis. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]