Configuration management, version 5

[Martin Oldfield <m@mail.tc>]

>>>>> "W" == Wichert Akkerman <wakkerma@wiggy.ml.org> writes:

--> snip <--

    W> 1. The configuration space All configuration information is
    W>    stored in what I
    W> call the configuration space. This is a database with a special
    W> design which resembles to method we look at configuration
    W> information. This is done by defining a hierarchy of
    W> information. Each package receives its own space in the
    W> hierarchy.  Each package is free to use a flat space, or divide
    W> it's space further into subhierarchies.  If multiple packages
    W> share a common purpose they may use a shared toplevel
    W> hierarchy, preferably with the same name as a shared (virtual)
    W> packagename (for example, both mutt and elm can use
    W> mail-reader, strn an nn could use news-reader).  This shared
    W> tree can also be used as a default, ie a variable
    W> news-reader/nntpserver can be used by strn if strn/nntpserver
    W> does not exist.

I think there are problems with a hierarchy, exemplified by emacs
which contains both a newsreader and a mail program. I suggest that
this implies the hierarchy either needs to provide multiple
inheritance, or is replaced by a simple list of the bits of the space
which are appropriate. In the case of emacs, this would be something
like mailreaders, newsreaders, emacsen, and emacs-19.

    W> 2. Types of variables
    W> Multiple types of variables can be stored in the configuration
    W> space. A preliminary list of types is: strings, numbers, lists,
    W> hostnames, IP addresses. Each variable can have meta-data
    W> associated with it for special purposes. The minimum meta-data
    W> associated with a variable is: long and short description,
    W> type, default value and an `isdefault' flag.  The `isdefault'
    W> flag states if a variable has been changed from it's default
    W> value. This can be used when upgrading a package to check if
    W> the user has changed the default, or it's safe to change it to
    W> a new default. This gives us the same result as the
    W> md5sum-checking dpkg does for conffiles, but on a much
    W> finer-grained level (per variable instead of per file).

I think there is a clear benefit to providing an ordered list of
information servers: if the config data isn't found in one place, the
next is tried. Then packages provide their default config in a low
priority database which obviates the need for the isdefault flag. As
an extra bonus, it's easy to return to the default installation at a
later date.

One disadvantage of such schemes is that it's not sometimes clear
where some value comes from, this problem is reduced if the script
which reads the config from the databases and writes it to the
program's config files comments the operation e.g.

# Taken from X
local_domains_include_host = true
# Taken from Y
local_domains_include_host_literals = true

where X and Y are the names of the relevant databases.

Cheers,
-- 
Martin Oldfield.


--  
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org