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

Re: [D-I] Supporting 2.6.14 kernels in base-installer



On Sunday 13 November 2005 08:16, Sven Luther wrote:
> That is less than 6MB of stuff, hardly "heavy". A single kernel flavour
> is double that for example.

That is exactly why we include only one kernel image on i386 netinst CD 
images.
If we'd follow the suggestion to support both yaird and initramfs-tools 
we'd have to include both perl and python in base installations. This is 
8MB (package size; installed size is a lot larger) in total and IMO not 
something to be happy about, and not only from a d-i point of view.

(Note that currently both perl and python are installed in 2nd stage if 
the "standard packages" task is selected; they are however not part of 
the base system.)

> Also, we have perl-base in base, or used to at least, would yaird not
> be able to depend on perl-base only ? Or did we do away perl-base since
> then ?

That would be very nice and actually conforms to what was done for 
localization-config: it was rewritten so that it needed only perl-base. A 
few functions may even have been added in perl-base to support this.

> > If we would install initramfs-tools, we would need:
> > - busybox
> > - klibc-utils
> > - mklibs-copy
> > - udev

waldi: Why is mklibs-copy needed?
Is it because of the same bug that caused failures on ppc and AMD64 for 
the gtk frontend? If so, could the regular mklibs be used now that that 
has been solved in binutils?

> Both should be installed into the netinst, and we should have a
> ramdisk-tool.udeb or a part of base-installer, which would default to
> one of them we chose as default at high priority, or ask the user at
> medium priority, a bit like what happens for grub vs lilo.

We absolutely don't need a udeb for this. The base system has been 
installed, so everything we need is available in the chroot. As the 
kernel is installed for the new system, initrd generation should take 
place in the /target chroot anyway (as is also the case currently).

Offering a choice to users is an option, but something that should be 
avoided if possible.

> Given the knowledge we have in d-i, we could even make the default
> dependent on the root choices made in the partman phase, and maybe even
> make it dynamically. We could implement jonas's probing proposal even
> though k-p doesn't use it, but ramdisk-tool.udeb could make use of it.

I'd rather the tools themselves and the kernel image postinst be smart 
enough about what they support and what not. Having that kind of logic in 
d-i sounds like a maintenance nightmare to me.

Attachment: pgpObYuK7tYIQ.pgp
Description: PGP signature


Reply to: