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

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.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.debian.org Links debian-announce debian-apache debian-arm-changes debian-beowulf debian-boot debian-cd debian-cd-vendors debian-changes debian-changes-digest debian-isp debian-kde debian-laptop debian-mirrors-announce debian-news debian-security debian-security-announce debian-testing debian-user debian-user-digest Request more information about Pantek

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.

-- 
To UNSUBSCRIBE, email to debian-cd-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


application/pgp-signature attachment: This is a digitally signed message part.