On Friday 14 December 2007, you wrote: > > 2) Creating a second Etch installer based on the new kernel > > ----------------------------------------------------------- > 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. Quoting myself: ! 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. ! ! And again I don't know who'd do the D-I work on it. I cannot even begin to oversee the consequences of the first point... > > 3) Using the Lenny installer to install Etch > > -------------------------------------------- > > The supported installation methods would be limited: no netinst CD or > > full CD. > > What makes these two methods problematic? The Lenny netinst and full CD images contain *testing packages* for the base system and will use these automatically with no option to use another suite. The businesscard CD does not contain any packages, but downloads the base system from the net, thus making it possible to select a different suite during mirror selection. > 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". Agreed. Although I'd say "inconvenience" rather than "complexity". > > 4) Option 3 + creating selected CD images based on the Lenny installer > > ---------------------------------------------------------------------- > > 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. Having -2.6-23-686 metapackages would not hurt and they could be passed to the 'kernel=' boot parameter instead of -2.6-23-X-686 variant. I don't think they would help for automatic selection of the "right" kernel, unless we add code to base-installer to prefer such metapackages over the -2.6-686 ones if the kernel major version matches the kernel version the installer is using. Note that such meta packages only have a very limited value: they will only help with ABI changing (security) updates during the lifetime of etch+1/2, but will not help with upgrading from etch+1/2 kernel to lenny kernel. > > 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) But only for CD-based installs, not for netboot.
Attachment:
signature.asc
Description: This is a digitally signed message part.