Re: Configuration management, revision 3
On Tue, 28 Jul 1998, Joey Hess wrote:
> Antti-Juhani Kaijanaho wrote:
> > I like everything about it, except the language. IMO it has the wrong
> > basic assumption, namely that the configuration module controls the
> > frontend like a programmer controls the machine (the language is
> > essentially astripped-down special-purpose BASIC). I would like the
> > language to be redesigned from scratch, with the assumption that the
> > module just _asks_ the frontend, and the frontend is free to either
> > 1) echo back the defaults the module has provided,
> > 2) return cached data or
> > 3) ask the user.
>
> But this assumption is already made! Notice in the proposal where it talks
> about non-interactive frontends, which take care of 1 and 2.
You are missing what he is saying. The current proposal is that we write
basically a script to handle the configuration prompting. A script is
probably necessary, but I think it probably should be in the post/pre inst
not seperate..
Anyhow, the point is that what you have is a package that has a set of
variables it needs, you should be able to describe THESE VARIABLES and not
THE METHOD TO SET/QUERY the variables, subtle difference.
For instance that current proposal does not seem to accomidate a master
index of possible configuration values and their meanings and types, all
we have a query language. [Envision downloading configuation.gz, firing
up your LDAP manipulator and configuring your machine -before installing-]
Just to be crystal clear, consider these two different setups.
PRINT "Is your clock in GMT?"
INPUT foo/gmt boolean true
SET foo/configd boolean false
STOP
And
Value: foo/gmt
Type: boolean
Query: Is your clock in GMT?
Default: false
Description: This value controls if your CMOS clock is in GMT or 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
Value: foo/configd
Type: boolean
Private: yes
Description: Controls some strange internal thing
Which is ultimately more usefull?
Personally I think the use of the query language as I understood it is not
what we -really- want, it serves the purpose of communicating (and
controlling!) the query process. What we want is a way to get/set values
out of the database, I've been thinking about something like this [excuse
my shell]
eval `do-query <<END
get foo/gmt FOO_GMT
set foo/configd yes
END`
The ideas is that with those parameters do-query would return
'FOO_GMT=true' which would then become a shell variable. A perl module and
a C routine could be created to complete the system.
The other 'missing' fragment is what to do if the user changes a database
entry once the package is installed. It is important to leave that
possiblity open so in future we can have 'push' configuration.
Jason
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: