Re: dpkg-db

[Tom Lees <tom@lpsg.demon.co.uk>]

On Sun, Jan 24, 1999 at 02:04:23AM +0100, Wichert Akkerman wrote:
> Shell interface: dpkg-db
> 
> The commands:
> 	create <variable> <template> <package>
> 		Create a new variable using <template>

It would be extremely useful to also have commands to add templates :)
Also, I liked the idea of template-groups, a template which generates
a "group" (you could call it a directory I suppose) of vars.

eg creategrp <path> <template> <package>

> 	remove <variable>
> 		Remove variable <variable>

A very useful feature might be "removepkg <package>", removes all tags
associated with <package>. Together with the dpkg-hooks thing, this could
be used to automagically clean these out on dpkg --purge (I think).

> 	check
> 		Check database integrety
> 	query <subcommand> <variable>
> 		Retrieve information about a variable
> 		Subcommands:
> 			value        - get value
> 			type         - show variable type

Presumably if we have types, there should be a standardized format for each
type (eg IPs have the dotted-quad notation as opposed to big hex number).
That's only a documentation thing though.

> 			default      - show default value
> 			description  - show short description
> 			ldescription - show long description
> 			defined      - check if variable has value
> 			meta <flag>  - check if metaflag <flag> is set
> 	(un)set <subcommand> <variable>
> 		Set or unset information for a variable
> 		Subcommands:
> 			value        - change the value. with unset we remove the value
> 			               from the database.
> 			meta <flag>  - (un)set metaflag <flag>
> ------------------------------------------------------------------------------
> 
> Feel free to make suggestions, since I haven't written a single line of
> dpkg-db yet.

These are some of the things I would like to see:-

* Definitely a library or CORBA interface to the thing (or even better,
  both), which is then used by the frontends.

> Please note we have three seperate entities:
> * templates: a description of variables, can define new variable types using
>   containers.
> * variables: a list of (template,name) pairs that define the variables
> * the database: place were we store the actual value for variables, if they
>   are defined. (ie the instantiations of the variables)

Some people wanted networkable databases and the like. I think the database
backend should be fairly configurable, so eg personal users would have:-

<directory / text>
dbdir /etc/cfgdb
</directory>

and eg big networks would have

# Fallback database
<directory / sql>
server sql.somewhere.com
db config_db
priority 1
</directory>

<directory / sql>
priority 2
server sql.somewhere.com
db config_db_hostname
overloads values
</directory>

<directory /printers text>
priority 3
overloads all
dbdir /etc/printer_cfg
</directory>

Basic ideas are:-

1) Databases may be overloaded either partially or completely. In the
   network example above, the config_db_hostname database is searched first,
   but for values only (all other types it is ignored).

2) Databases may be inserted at any point in the structure, eg /printers.

-- 
Tom Lees <tom@lpsg.demon.co.uk> <tom@debian.org>  http://www.lpsg.demon.co.uk/
PGP Key: finger tom@master.debian.org, http://www.lpsg.demon.co.uk/pgpkeys.asc.