Re: dtxtdb, further directions.
On Thu, Dec 4 1997 21:14 GMT Tom Lees writes:
> > If yes: which future enhancements are necessary?
>
> Make it required by policy. This is The Only Hope for getting anyone (and
> everyone) to use it.
Ok, I'll ask on debian-policy about that.
> Apart from that, here are some features I would personally like to see:-
>
> 1. Seamless integration of conffiles into dtxtdb, i.e. if a particular
> variable is managed by dtxtdb, dpkg's conffiles should ignore any changes
> to it (in cases where it must be put directly into a script).
I'm not sure, whether I understood this correctly. The goal of dtxtdb is
that every pacakage maintainer, who wants to store name/value-pairs uses
dtxtdb for that and, hence, the script can be exchanged. This would alleviate
the problem we have at the moment: if you change some configuration value in
a script, the whole script will be marked as conffile and you have to sort
out the differences from the old to the new version by hand.
> 2. Configuration profiles with inheritance. So, for example, I can make
> three "configuration profiles", each modifying different parts,
> e.g. I might have the following profiles:
>
> Hercules
> Matrox
> Local_Customization
> Local_Network
> Network_Server
> Network_Client
> Toms_Machine
>
> The idea here is that I could export the configuration db to many machines,
> and have each one select a group of configuration profiles, so, for example,
> I could have several machines (all with the exact same hardware) with the
> Hercules+Local_Customization+Network_Client profiles.
This would be possible by extending the CFGDIRROOT to a CFGDIRPATH variable.
This would loose the 1:1-mapping though: all the files in the CFGDIRPATH
would be merged and exporting them to another machine would merge all
the values into a new configuration. Is it this what you indend?
> Also, integration of the configuration database into misc. bits and pieces
> (like the init links) would be useful.
This should be done by the package maintainers (particularly init
and net{std,base,...}).
> Another feature (although this a _very_ long term) would be a good
> rollback system (maybe it could integrate at system boot).
Sound's good. At the moment there is nothing to rollback. If this is really
wanted/needed one would have to keep a history for each entry (changed), in
order to be able to roll-back. This sounds like overkill to me; either use
RCS to version control your database or use something like pqfs(?) [Postgres
file system] right away.
> > 2. Do we want it to drop it altogether and wait for something better
> > (The Caldera Admintool, for example).
>
> Can they be integrated?
After reading the COAS paper, I would say yes. COAS would include a
`database backend' which could be replaced by dtxtdb, if we want to.
David
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-admintool-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: