Re: Configuration management, revision 3
On Tue, Jul 28, 1998 at 06:53:09PM -0700, Joey Hess wrote:
> Yes, I understand the distinction. I see the advantages to having a set
> of questions, rather than a script. But I doubt it will be flexable enough.
You just have to design the language to be flexible enough. In this
post I'll sketch one. The design I describe below is not meant to be
implemented as is, it is only an illustration.
Let's start with a very simple package, xyzzy. The only thing it
needs to know is whether the system clock is set to UTC or not.
Consider what kinds of frontends we might have. One is the archaic
"return the default at all times" (call it the dummy). A more
flexible one, called lineconf, will ask the user the questions one at
a time, like our current cofiguration process does. One could also
design and implement a fancy graphical configurator - called here the
kitchen sink - that has many bells and whistles.
Now, how should the simple UTC question be presented in these
frontends? The dummy will just return the default (yes yes leave me
alone will you!). The lineconfig asks, "Is your system clock set to
UTC (Y/n)?" The kitchen sink will pop a nice window at the user, with
the title "Is your system clock set to UTC?", with two buttons (Yes
and No), containing this long explanatory text: "This value controls
if your CMOS clock is in UTC. If it set to true then no timezone
conversion is done on boot and you do not need to worry about daylight
savings, but your clock will not be compatible with Windows/dos. If
false then you will have to correct your clock after daylight savings
changes." (this particular example was from somebody else's post)
How to present this to the frontend? Clearly we need to give it a
named aggregate of pairs (consisting a label and a datum). One pair,
for example, might be labelled "type", referring to the type of values
wanted, and its datum could be "yes/no". The syntax for communicating
the aggregate is not really relevant to this illustration, but for
clarity's sake I will need to pick one. The one I pick owes much to
Lisp and Scheme. It is not the only option, however.
In the syntax I pick, the aggregate describing the UTC question would
look like this:
(datum xyzzy/utc
(type yesno)
(query "Is your system clock set to UTC?")
(explanation "This value controls if your CMOS clock is in UTC. If
it set to true then no timezone conversion is done on boot and you do
not need to worry about daylight savings, but your clock will not be
compatible with Windows/dos. If false then you will have to correct
your clock after daylight savings changes.")
(default yes))
You'll notice that every compond object is in parentheses. The
outermost partheses delimit the whole aggregate, which consistsi of a
keyword (here "datum"), the aggregate's label (here xyzzy/utc,
referring to the config variable we are interested in) and a series of
attributes.
The attributes are, again, all within their own parentheses. They
consist of a keyword identifying the attribute (here "type", "query",
"explanation2 or "default") and of the attribute datum.
A more complex package would simply put several of these aggregates in
a row. For example:
(datum doc/manpath
(type searchpath)
(query "What path should be used by default when searching for manpages?")
(explanation "The Debian system comes with documentation. A part of
it consists of a collection of short descriptions of commands,
system calls, games and other things. These descriptions are
called 'manual pages' for historical reasons. If you install
software that did not come from the Debian distribution, you may
have some manual pages that Debian's documentation system as configured
by default cannot find. In such a case you may want to add the
directories where these additional manual pages may be found into
the list given here. Normally, however, you wouldn't need to change
this.")
(default /usr/share/man:/usr/man))
(datum doc/infopath
(type searchpath)
(query "What should be the default info file search path?")
(explanation "Some of the documentation that Debian ships is given
in GNU project's info format. If you install software that did not
come from the Debian distribution, your system may
have some info files that Debian's documentation system as configured
by default cannot find. In such a case you may want to add the
directories where these additional info files may be found into
the list given here. Normally, however, you wouldn't need to change
this.")
(default /usr/share/info:/usr/info))
This is all given to the frontend in one batch. It will then use some
other means to give the config module the answers.
> Consider some examples of the questions asked in postinsts now. They often
> go through a tree of possible questions and subquestions:
>
> Do you want me to do foo?
> yes
> Do you want me to do foo2 as well?
> yes
> no
> What about foo3?
> yes
> no
> no
> Well then do you want me to do bar?
> yes
> no
>
> How do you present this in a simple database of questions without presenting
> the user with a coplicated mismash of questions?
You probably think that the scheme I outlined above is not powerful
enough to handle your example. You are right. We need a way to
express the interdependencies between the data.
Consider what the different frontends would do to your questions?
Dummy would always return the same set of answers. Lineconfig asks
the questions in the manner you present. Kitchen sink would present
them all in one window, disabling those checkboxes that would be
irrelevant considering the current set of answers.
This is how I would present the questions above:
(datum metoo/foo
(type yesno)
(query "Do you want me to do foo?")
(default yes))
(if (yes? metoo/foo)
((datum metoo/foo2
(type yesno)
(query "Do you want me to do foo2 as well?")
(default no))
(datum metoo/foo3
(type yesno)
(query "What about foo3?")
(default yes)))
(datum metoo/bar
(type yesno)
(query "Well then do you want me to do bar?")
(default yes)))
You can probably quess the syntax and semantics, but I'll give
a brief summary:
(if <condition> <then-part> <else-part>)
(yes? <a yesno config variable>) - evaluate to true if variable is yes
(<object> <object> <object> ...) - a grouping
Other conditionals are also feasible.
Note that the order of data is immaterial. metoo/foo could easily
have been declared after the if block. This is because this is not a
program, it is a description. The lineconfig will probably slurp this
and topologically sort the questions in order to get the order of
questions to be asked. The kitchen sink will probably slurp this too,
and provide a layout for the questions on the screen so that their
dependencies are easily seen. It should also disble those checkboxes
that are not relevant considering the current set of answers - for
example, bar should be disabled whenever foo is yes.
I realize that this language requires a more sophisticated parser than
Akkerman's original, but IMO it would be worth it. And I don't think
the parser needs to be /that/ sophisticated :-)
Comments?
Antti-Juhani
--
Antti-Juhani Kaijanaho <gaia@iki.fi> ** <URL:http://www.iki.fi/gaia/> **
I can't seem to find a lowercase 'r' on my keyboard.
(Lee Davies in comp.unix.programmer on July 22, 1998)
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: