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

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



(Not CCing -release, -kernel and -x as I assume the relevant people will be
subscribed to the project list. Please follow-up to all three lists.)

On Tuesday 23 October 2007, dann frazier wrote:
> Now that 2.6.23 is out and the proposed timeframe for etch 1/2 is
> just over two months away, its probably a good time to start making
> some progress on an etch 1/2.

I have been thinking on and off about options how installations for Etch 
using a newer kernel than 2.6.18 could be supported by D-I and CDs.
I have never been particularly happy with the conclusions I came to and thus 
have been somewhat sceptical about the practical feasibility of the whole 
etch+1/2 concept.

However, I think I now have some possible options fairly straight in my head 
and even feel some of them could work in practice. So here they are.
Note that these are my current, personal thoughts. They have not been 
checked with any other members of the D-I team or anybody else.

I've come up with four options:
1) a new version of the Etch installer with support for both kernels
2) creating a second Etch installer based on the new kernel
3) using the Lenny installer to install Etch
4) option 3 + creating limited CD images based on the Lenny installer

Below an analysis of these options.


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.


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. 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


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.
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).

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.


Hope this helps, or at least informs.

Cheers,
FJP

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: