Installation-time Configuration
After having received some comments on my previous post on this topic,
I wrote a new text today which is somewhat more detailed and shows what
I would like to do, and more of how I think it should be done. Here
it is:
The package
===========
We want to make a package which does not break older dpkg's, and we want
to be able to get the configuration information before the preinst is run,
which means before the package is extracted. Since dpkg extracts the
control.tar.gz part of a package before data.tar.gz, we can simply use
a new control-file for the configuration module. (NOTE: this is a change
from the first draft, since I didn't realize then that dpkg unpacks
data.tar.gz at a later time). Since older dpkg's will not look at the
extra file, we can do to things: either create an extra assertion
"--assert-configmodule" in dpkg, or up the versionnumber of the package.
The configuration space
=======================
The configuration space is the realm in which all configuration information
is stores. This space is divided into different sections in the same way
a filesystem is. The toplevel-hiearchy is for package: each package has it's
own configuration data in a folder of the root. Packages which share a common
purpose may use a shared folder, preferable with the same as as a shared
(virtual) packagename (for eaxmple, both mutt and elm could use mail-reader,
strn and nn could use news-reader). Within a folder the configuration items
(variables) are stored. Each variable has associated with it one or more
tags (meta-information). These are used to detect if a variable has been
changed by the user or not, in much the same manner as md5sums are used to
detect changed conffiles.
Managing configuration space
============================
To access the configuration space a library is used. This library implements
all functions necessary to retrieve and store both information and meta-
information. There will also be a command-line utility (dpkg-var?) to retrieve
information from scripts.
Communication between configmodule and the user
===============================================
This communication should be as simple as possible. The simplest method
possible is using stdin/stdout to communicate. When dpkg runs the configuration
module it connects the stdin/stdout from the configmodule to the stdout/stdin
of the frontend, allowing the two to communicate.
There are two types of frontends possible: interactive and non-interactive.
Interactive frontends allow the user to answers questions and see messages.
Non-interactive frontends get all information from a database (SQL, LDAP,
db, textfiles, etc.). If a non-interactive frontend is used and the
configmodule refuses to accept the information the frontend retrieves, it can
exit with a non-zero exit code, indicating to dpkg it's not possible to install
the package with the current configurationdatabase. Both frontends use the
library mentioned before.
Most IO implementations default to line-buffered IO, so we use a simple
language where each command is exactly one line. A prelimary list of commands
is:
VERSION <number>
The version-number of the communication-language the module will use.
CAPB
Asks the frontent for a list of capabilities. The includes interactiveness!
RESET
Clear the accumalated set of TEXT and INPUT commands
TEXT <string>
Show a string to the user. The string is need not be shown until a GO
command is given.
INPUT <comment> <type> <variable>
Asks the user for to enter a value of type <type> which should be stored
in <variable>. Show <comment> as a comment before the inputbox/line. If
<variable> has been given a value with SET use that as a default. This
question is not asked until a GO command is given. This allows us to ask
multiple questions in a single screen.
GO
Show the current set of accumulated questions to the user and allow the
user to change the answers.
UNSET <variable>
Remove <variable> from the configurationspace
SET <variable> <type> <value>
Set a variable <variable> of type <type> to <value>
DSET <variable> <type> <value>
Set a default-value. Same as above, but changed change <variable> if the
last change has been made by the user.
GET <variable>
Return the value of variable <variable>
STOP
We are finished. Store the new variables now if transactions are used
and flush the diskcache to make sure we don't loose anything.
The frontend responds to each command by returning a status code and,
if needed, extra data after the status code.
The frontend has complete responsibility for the layout of the questions,
with the exception that the ordering must not be changed.
Attachment:
pgp0l6uLQizhB.pgp
Description: PGP signature