Re: dcfgtool and clones
On May 30, Tom Lees wrote
> We are planning on expanding the scope of deity to include a few more
> features than "just a GUI" after the initial release though. Including
> getting a decent library set together for other developers to use. Making
> the config-tool part of this would seem pretty logical.
and where is that configtool ? we don't have one, and nobody is working
on one (IIRC). all we have are those text databases (configtooll, nod,
dcfgtool, dtxtdb). it's like dpkg and dselect : one is the base tool,
and the other one the gui.
the dtxtdb will be universal enough, to fit any gui you will write. but
there is no reason now to care for a might be coming sometime gui.
and even if someone writes a gui to configure debian : there are much
worse problems than dtxtdb. look at the structure of config files like
uucp sys config file : if you can manage this, you can manage nearly
everything (including dtxtdb).
cfgtool is a bad name, and it was it all the time. but even if we keep
to the name cfgtool, what you are talking aboout is the admintool - a
gui and inteligent program to configure debian.
> > > b) change policy to _not_ allow config information in /etc scripts
>
> I really don't like this, and I think several others don't either.
code is code and data is data. many scripts have both in them, causing
many problems when updating. and a lot of debian developers start to
move data out of their scripts, but everyone uses his own way.
> > > c) change policy to _not_ allow additional debian uniq config files to
> > > fix b). only the textdb should be used.
>
> Definitely. But we have to remain backwards-compatible, so we must be able
> to *read*, e.g. /etc/mailname, to be able to convert to the db.
that's ok, because many programs use it. i was thinking about files like
/etc/gpm.conf, only used by /etc/init.d/gpm, and others. so, what about :
c) change policy to _not_ allow additional debian uniq config files, if
they are only used by scripts.
> > > d) think about getting rid of some config files only used by shell
> > > scripts, and use the textdb instead.
> > yes.
> Do you do any hashing? I usually use gperf to generate a hashing function
> for the main keywords. This really does give some nice speed improvements.
it don't why anyone considers speed. if we only store data we currently
store in scripts, we will have less then 30k data. divide that in
several files, and you will have files < 5k. and you will need to read
these files 100 times at bootup, and nearly never during runtime.
and all these values are worst case, based on current /etc i will get
only 8k total (that's 2k per file or so). if the whole program is
written in c, it's very fast. no need to make thoughts about speed. we
can do that, if the program is going to be slow, but everything points
to be a very fast program.
> > Finished in about a week (beta version).
>
> Great! Are you planning on uploading it to experimental or unstable? I
> would suggest you upload it to experimental, as it has the possibility to
> severely corrupt people's systems. OTOH, you could also put it in your
> home on master, as a pre-beta to check if everyone likes it.
it can not corrupt any system, because there are no packages that will
take use of it, as long as package maintainers don't modify their
scripts to use it.
> > Mailing list other than debian-admintool: no
>
> Maybe we should start *using* debian-admintool then :)
if we had something other to discuss than to worry about speed and gui
details ...
> > Tom Lees <tom@lpsg.demon.co.uk> said:
> > > It would be really cool if we upgraded the packaging system to handle
> > > configuration integrally (so we can do configuration _BEFORE_ an
> > > installation, etc.).
> > Yes. But the tricky part is how to rewrite all the /etc/hosts, /etc/networks,
> > /etc/uucp/{sys,dial,port,config}, /etc/fstab, /etc/slip.dip etc. files.
> > I don't have an idea.
no, don't do that ! it's not your job. that's the job of an admintool,
not the job of the dtxtdb. also /etc/fstab and /etc/slip.dip are real
config files, we may not touch them.
all we should do for now, is provide an utility as replacement for one
config file, where currently is none, or where we have a propietary
config file for one script (that's pointless).
if someone want's to write an admintool - he would have well known uucp
cpnfig files to work with. he would have well known smail config files
to work with. the only things he has no config file, are these damned
scripts with only one variable, changing from version to version. he
shouldn't bother with them ans have a real config file. but we don't
want one big config file to configure everything (like german suse
distribution), and we will provide an interface to dtxtdb as
replacement.
everything dtxtdb should do is provide a replacement for a config file,
where there is no, but tens of scripts and propietary files with only
one or two values.
> How about we do it like apache does its modules? (This might get tricky,
> as I'm not sure all developers can program).
again, that's a way an admintool could work, but not a way for a small
text database.
> So the config tool loads all the modules (using libdl), and then it
> can use special functions in these modules to handle these
> file-formats. OTOH, there aren't that many files with non-generic
> syntax... maybe we could simply include separate parsers for each of
> these.
IMO the task of parsing config files like uucp sys config should have
it's own script language (or some MAKROS for yacc). the developers
shouldn't have to program a parser in c.
> The way I envisaged it was that Deity would get all the configuration
> info, and then pass it on to the back-end after it had all the info.
> I think the cfgtool should probably be available as a shared lib so that
> deity can also read stuff etc., without too much of a slowdown from
> execing another prog.
again, that's what an admintool could do, not txtdb.
system configuration would work in three layers :
a) config files like uucp sys config
b) the admintool, that has a large background knowledge (help texts,
possible values, structure of config files, ways to parse, write
and change them etc.)
c) the gui
deity can help with c)
txtdb provides an interface for variables currently in scripts and goes
into a). but it doesn not do anything for layer b) and it will live side
by side with uucp config files, smail config files etc. and wwill not
touch them.
b) is the big problem. don't you want to do that task ?
> > You can store a comment (a la dcfgtool), but the other things are not here.
> > dtxtdb knows about booleans, ints, floats and strings. That's it.
>
> I suggest another two types (although they are really special cases) - IP
> address, and FQDN. The regular expressions to handle these really are too
> long for something that will be in common use.
parsing config values and checking them is something for layer b), the
admintool. (nobody checks smail config files when you edit them with vi
- if you use this low level method, smail will not work if there are
errors in there). dtxtdb should be a very low level program, and not
more.
regards, andreas
--
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: