Re: [D-I] Supporting 2.6.14 kernels in base-installer
On Sun, Nov 13, 2005 at 08:28:47PM +0100, Frans Pop wrote:
> 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.
Well, so what ? I mean, the netinst on powerpc is around 240MB or so, no, what
is 8MB more or less ? The only moment this would be of consequence would be
if this space would be sorely missed in filling up the first CD, but i guess
there are good chances that those packages are already on it, no ?
> (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.)
Exactly what i said above.
> > 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.
Erik, Jonas, comment about 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.
Yeah, so, we don't offer the user choice of grub or lilo right now ?
I mean, i definitively said we provide a sane default at high priority, and
let the user chose at medium priority, for expert installs, or is this second
case also something where choice needs to be avoided as much as 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.
Ok, i repeat myself again. The tools have knowledge about this, and d-i could
then easily probe them thanks to the current
--supported-(host|target)-version, and the future --supported-<capability>
than jonas proposed, where capability would be something like evms root, or
such. The installer obviously knows what his situation is, since he installed
them, and can, for a list of possible tools probe them for this situation, and
eliminate those that are not suited, providing a sane default, and leaving the
user with a meaningful choice that will not hose his newly installed system
when in expert mode.
So, this is exactly what you ask, the knowledge about what the tools support
is embedded in the tools, and the kernel itself would be able to do the right
choice, provided both where installed.
We could even do this fully outside of d-i, provided there was a possibility
to have dependencies filled out by the postinst or something such, but we
don't have those, so ...
Friendly,
Sven Luther
Reply to: