Re: [woody,debinst] (Was: Re: [dbootstrap] `newt' and `boxes.c', `bogl' and `bowl'[, `???' and `boxeX.c'?])

[Bruce Sass <bsass@freenet.edmonton.ab.ca>]

On Sat, 17 Jun 2000, Joey Hess wrote:
> The ideas I stress are important are:
> 
> 1. Modularity.
> 2. Do the absolute minimum in the installer, do as much as is possible
>    in the full debian install.

A side effect of both these points is that the installation system
should become scalable and get smaller...  Is it necessary for the
installer to contain complete packages for the code it uses?  e.g., if
the installer uses dpkg, does everything present in dpkg...deb need to
be hanging around. 

<...description of a dpkg based installation system...>
> I think this would require a minimum of 16 mb of disk space, and
> probably a bit more. Since with ramfs, disk space == memory, this
> would limit installations to systems with around 20-32 mb of memory.
> I don't think that's very acceptable.

Are these estimates based on the "installed size" of the necessary
packages, or a guess at the amount of _required_ code?

I'm just wondering if I am missing something: libslang, libreadline,
libc-2.1.3, /usr/lib/dpkg, libapt-pkg, libnewt, libgtk,
/usr/bin/dpkg,apt,bash}* ~= 4546k

> > Partitioning could be done via debconf.
> 
> Debconf's frontend is too inflexible for a partitioner, you need a real UI
> there.

Hmmm, what would it take to have the debconf engine handle something
like this... it would be nice if users had the same basic UI handlers 
for installation, configuration, and maintenance.

> The question of how the UI should work is the weak point of my current
> proposal. I've been wrestling with really two orthagonal issues:
> 
> 1. How should the UI work? I rather like most of our current UI, but
>    is it really the best way to handle things or have I just become
>    accustomed to it? My proposal is to have a modular installation
>    system, which means that modules need to be able to hook into the
>    UI. Note that this is not about UI toolkits, but about UI design.

Is this the level of design you are thinking of...

<<installer mainline>>=
    <setup the installation system>>
    <<scan the box and define default modules>>
    if inmanualmode then
        <<let the user define the system>>
    while not DefinitionPassesSanityCheck()
        if inautomode then
            <<handle auto-install problems>>
        else
            <<let the user define the system>>
    <<install a pre-defined system>>
    <<do post-installation stuff>>
    @

<<let the user define the system>>=
    <<present modules that could be configured>>
    <<mediate between the user and debconf>>
    <<write system definition file>>
    @

<<mediate between the user and debconf>>=
    notdone = TRUE
    while notdone
        if selected-a-module then
            configure-module-via-debconf()
        elseif signalled-all-finished
            notdone = FALSE
    @

[wrapping pseudo-code in noweb markup seems like a good idea.
does it work?]

In this scenario the installer doesn't need to know much about
modules in general; although it will have blank templates for hardware
modules, and will need to know how to fill them in to the point where
debconf can take over.

> 2. How should information from the UI be stored, for use later on (and,
>    presumably, for use in a kick-start like thing to anable mass installs)?
>    Here debconf seems like a fair fit, although it would have to be
>    redone in C.

In a text file along the lines of the kernel's .config file, created
from a debconf backend DB...?


later,

	Bruce