[Debconf-devel] Debconf config handling

Nicholas Bamber nicholas at periapt.co.uk
Fri Dec 2 20:31:39 UTC 2011


I have found that to manage the config of one of my packages correctly I
would need to use the techniques described in ADVANCED PROGRAMMING WITH
DEBCONF/Config file handling from the debconf-devel(7) man page and that
in this case the config files are formatted using a python like syntax
rather than shell environment variable setting syntax.
So I was looking at my options.

Exim takes an approach that allows the user to make config changes but
also integrates with debconf. However it is not perfect since the real
config is stored in /var and only the templates are stored in /etc and
one needs to know m4 (admittedly easy enough) to use it.

I think a more general approach is not difficult to formulate and I here
propose a system that for the purposes of this email, I will call
"debconf-screwdriver".


Top-level
=========
The core of the proposal is a script with this syntax:

debconf-screwdriver --rules <file> --target <config file> --mode
[tighten|loosen] [--backup <file>]

In "loosen" mode the screwdriver reads the config file and according to
the rules file extracts the settings and writes them to debconf. In
"tighten" mode the screwdriver reads the config file, reads the settings
from debconf and writes out a new config file merging the two
and optionally providing a backup file.

So the beginning of the config script would use the screwdriver in
loosen mode. The postinst would use the screwdriver in tighten mode and
in the case of an aborted upgrade mught copy from the backup.

Although the rules files could be anywhere on the flesystem, it would
make sense to pass them along in the DEBIAN directory part of the
package. This would sugggest a new debhelper Sequence command making
debconf-screwdriver both an install and a build dependency.

Implementation
==============
The core of the implementation would be a Perl object class
(Config::Screwdriver::Rule). This would have name, get and set methods.
 The name method would be fixed at construction
time. The get method would take a string representing the contents of a
config file and return the value on success or undef in the case of no
match. The set method would take the same string and a value, and either
return either the merged string or undef if there was no match. This
would be a OO class hierarchy and the most basic implementations
would capture simple assignments but boolean states and lists would be
other instances. A rule is suppsed to be idempotent, so that if one gets
a value and then immediately sets the same value one should have the
same string.

A Config::Screwdriver object would be a set of rules applied in a
particular sequence. One would construct one with an array ref of
Config::Screwdriver::Rule objects. Its Loosen method would take a string
and return a hash ref. Its Tighten method would take a string and a hash
ref and return  a string.

So now the debconf-screwrdiver tool simply has to parse the rules file,
instantiate a Config::Screwdriver object and pass the config file
contents through. The format of the rules file would be a list of the
Perl classes used (always a subclass of Config::Screwdriver::Rule) and
the arguments to instantiate them. The first argument would always be
the name.

Reflections
===========
Since the Config::Screwdriver class does not itself depend on debconf
and could be independently useful I would publish it to CPAN.

However as far as I can see there is already a tool in the same problem
area, namely Config::Augeas. I can think of several reasons for not
using Augeas, but it is a serious system so there would be a reason for
architecting the script so that systems like Config::Augeas could be
adapted as the core module.

I have been trying to think if this proposal would be hopelessly
inefficient. As far as I can see it would not be very diffirent from a
series of grep and sed commands, but would be much more robust and
flexible. I am not about to launch into this project as I am not yet at
the point where fixing my package's configuration issues become
overwhelming but I would welcome feedback on the idea.

-- 
Nicholas Bamber | http://www.periapt.co.uk/
PGP key 3BFFE73C from pgp.mit.edu



More information about the Debconf-devel mailing list