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:
pgpmrt5tlWpdc.pgp
Description: PGP signature