Re: [woody,debinst] (Was: Re: [dbootstrap] `newt' and `boxes.c', `bogl' and `bowl'[, `???' and `boxeX.c'?])
On Sun, 18 Jun 2000, Joey Hess wrote:
> Bruce Sass wrote:
<...>
> > <...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..
Ya, if the installer isn't modular ;). I didn't attempt to estimate how
much of the code included in the total was unnecessary... take what you
need and dump the excess.
> > > > 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.
Hmmm, you could...
> > <<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.
(ok)
> 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.
...let the modules themselves do anything special they require. If
debconf gets a message it doesn't understand it could simply pass it
onto the module. Or would this require a new class of configuration
variable, one that defines a command to be executed by the module being
configured? e.g., a HD module could define a PARTITION command variable
and debconf, seeing that it is flagged as a command, would pass it onto
the HD module; which would query debconf for whatever else it needed
(number and sizes of partitions,...), partition the harddrive (or fire
up its own UI, or start a standalone partitioner), then tell debconf to
set the PARTITION variable in the DB if there were no errors.
later,
Bruce
Reply to: