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

Re: PROPOSAL: Just say no to database based admintools - Use parsers

[Sigh, for (n+1)th time, no need to Cc:]

On Wed, Jul 9 1997 12:00 +0200 Andreas Jellinghaus writes:
> > > In contrast, the article pointed out
> > > that MS Word has become this enormous, do everything, buggy piece of
> > > bloatware (my exaggeration).  I see the dtxtdb as a centralized
> > > duplication of /etc (i.e., bloatware).  I have lost interest in the idea.
> again : my goal for dtxtdb is to store the OPTIONS= lines of all
> /etc/init.d scripts, that's all. 
> dtxtdb has nothing to do with the "build a huge database" discussion.
> please, do not refuse the dtxtdb concept, because of some "dreamers".

I agree 200%. 

> and for the other people : if you don't talk about the dtxtdb concept,
> please make it clear to everyone, that you do not.

Yes, please.
> David Frey wrote :
> > We haven't settled the issue yet what to do with the standard configuration
> > files as /etc/hostname, /etc/uucp/*, /etc/smail/*, etc.
> > 
> > Several people already pointed out, that it would be nice, if we could
> > separate the data from the shell scripts and put the data into configuration
> > files. Soon after, I wrote dtxtdb along the ideas of Andreas' dcfgtool.
> > It's only purpose it to set and read back variables which were set by scripts.
> > (You could source [with sh(1)] the config files, if you want to, but dtxtdb
> >  does some quoting and locking).
> again, for everybody:
> fact 1) many /etc/init.d/scripts contain some configuration variables
> 	(like OPTIONS= lines or out commented programs)
> fact 2) several developer started to move these informations out of the
> 	/etc/init.d/ scripts. so for 3 developers we haev 4 very
> 	different ways to do this.
> fact 3) we need to extract these config variables from the scripts.
> fact 4) if every developer uses it's own method to do this, we have chaos.
> fact 5) the easiest way is to have a /etc/config.d/file for each
> 	/etc/init.d/file and source these file to get the options.
> fact 6) using a small database like tool (dtxtdb) can give much more 
> 	flexibility.
> we _don't_ want : 
>  - replace well known config files (/etc/hosts, /etc/smail*, /etc/uucp/*)
>  - copy the information of well known config files into the database.
>  - blow up the database with adding timestamps, history, help texts,
>    lists of possibilities or whatever you want to see in the database

Again agreed.
I added my paragraph just for the completeness' sake to show the direction.
At the moment, I'm against the approach of parsing well-known configuration 
Do it step for step!


TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: