Re: [woody,debinst] (Was: Re: [dbootstrap] `newt' and `boxes.c', `bogl' and `bowl'[, `???' and `boxeX.c'?])
Bruce Sass wrote:
> > 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...
You becha.
It should also be possible to easily create customized installation systems
if you know what media you are installing from. For example, if you only
want to be able to install from http on systems with ethernet, you need
a file retreiver that does http, ethernet drivers for the systems you
want to install on, the installer glue code, and the UI. It is at least
possible those four components will be small enough to fit on a floppy.
The other required components (partitioner, etc) can be downloaded as
required.
> 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.
No, I think we'll want to keep the packages ultra-stripped down.
No docs, etc. (Dpkg is a bad example, because I doubt we'd pull
in dpkg; seems more likely we will have a dumb little script that
pulls debs apart on its own using 3 programs from busybox.)
> <...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
You need to throw in some more space for glue code, kernel modules,
ldso, etc. Still, perhaps my estimate was a trifle high.
However, if we used all this stuff, we would have a minimum of a 4 or 5
floppy install, right? I don't like that. I'm hoping one floppy installs
fall out of this redesign, although they can't be the primary goal..
> > > 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.
Debconf is really based on the assumption that it's going to be asking
the user a series of simple questions. There are no provisions for more
complicated UI's that would probably need callbacks, widgets, etc, to
implement.
> > 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>>
> @
Not exactly the level I was thinking on; I actually have similar stuff
roughed out already.
> <<let the user define the system>>=
> <<present modules that could be configured>>
> <<mediate between the user and debconf>>
I think the part I'm particularly interested in is how the modules hook
into the configuration system. If they do use debconf, we have a
well-defined set of hooks already (templates and config scripts). If not,
we need some other plan. I'm interested in speccing out whatever it is
as a level of detail that will let modules be written.
Maybe it'd make sense to just make the modules default to using
debconf, which should be accepatble for most of them, and allow
exceptions like the partitioner include their own UI code, that hooks
into the debconf backend.
--
see shy jo
Reply to: