[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Configuration management, version 5



Wichert Akkerman wrote:
> * all proposals for a file with the variable list share 1 thing: the priority
>   of a variable is given in this list. I don't think that is reasonable though:
>   we can't always know if a variable is important until we know the conditions.
>   For example: if you configure sendmail as a nullclient, it is critical to
>   know the smarthost. In all other situations knowning the smarthost is not
>   important at all.

I think we should at least have a default priority.

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

I see you've added "isdefault" back. It is unncessary, because we have a
default value now. It's simple to compare the default value with the current
value to see if the value has changed, therefore an "isdefault" flag is
superflous.

> (This format is heavily based on the bind named.conf format: it's quite
> easy to parse and very flexible.) . We start by defining the databases
> to use. Each database has a driver to use and a root from which we start
> looking.

Would it be possible to "mount" multiple databases at the same root? This
would let you use a remote db to pull in initial values, and write changes
out to a local db (both "mounted" at /).

-- 
see shy jo


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


Reply to: