[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: etch+1/2 D-I options (was: Meeting for etch and a half)

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

Reply to: