Re: PROPOSAL: automatic installation and configuration
Amos Shapira <firstname.lastname@example.org> writes:
> [1 <text/plain; us-ascii (7bit)>]
> From: Massimo Dal Zotto <email@example.com>
> > Whichever automatic installation system we decide to introduce in Debian,
> > a reorganization (more or less substantial) will be absolutely mandatory.
> > The current configuration method is totally incompatible with an automatic
> > installation system, and the best installation tool we could design would be
> > totally useless unless *ALL* packages have been made compatible with it.
> I think I understand what you mean by that and agree with it.
> I did some more thinking about the proposed system and noticed that
> even, for instance, it is used with an X11 interface to pop-up a
> window for each question individually, it can get quite annoying to
> the user.
Yep, it can and will.
Ever compiled a kernel? I'm using a very similar parser to generate a
"make menuconfig" like interface from the config scripts provided by
packages (at the moment only my patched qvwm package).
The parser runs the config script with a substituted question
programm, that actually outputs the relevant entries for lxdialog. The
result will be entered directly into the packages database (and the
defaults read from there), unless otherwise marked. On exit the
interface then runs all config scripts that have changed values in
The same script could be used with gdialog or another parser could be
written for tcl/tk. I myself will also write a parser that provides an
interface via http once I got the menuconfig parser running reliable.
> Another option to do this without needing a major reorg might be to
> instruct script writers to concentrate ALL the questions as early as
> possible in the script, hopefully in one large chunk. That way it
> might be easier to replace the entire chunk of questions with some
> database-access command (or consolidate the questions in a single GUI
Bad idea. Some questions depend on the answeres of others or on the
systems state. You will have commands inbetween the questions and then
you probably won't detect them correctly. A special syntax, as
stated by my proposal, is needed to make parsers aware of stuff they
need to evalueate or skip.
> > If we design a general enough dpkg-getconfig/dpkg-message API we could later
> > replace the initial tool with a much more sophisticated one, possibly using
> > a totally different user interface or method for handling the configurations.
I'm already working on a general and suffisticated tool.
May the Source be with you.