Re: dcfgtool and clones
On May 26, David Frey wrote
> Lars Wirzenius <liw@iki.fi> said:
> > Assuming the syntax is simple, and there's no need for complexity, a
> > hand-written parser can be lightning fast, and all the time is spent
> > in starting the program, and reading the file.
> Mine is currently a lex parser and a yacc scanner.
great. that shouldn't make the binary fat, i hope. and anyway, lex &
yavv are perfect for such a use.
> 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.
your tool shouldn't do that. only add some config files, where now
variables are in various scripts (etc/init.d/*) or have their own config
file for one liners (/etc/ppp/, /etc/gpm.conf ...).
> > Deity definitely _IS_ the right place for this -
> > a GUI to do the configuration with, at the same time as packaging
> > control!
> I'd prefer a back-end and deity would be the frontend.
it's not important if there are two seperate frontends or if their is
one. we will need an admintool first, and who will program such a
thing ? it would need a lot of flexibility to handle many very different
config files.
> Jason Gunthorpe <jgg@gpu.srv.ualberta.ca> said:
> > To allow a GUI to present a usefull view of the config file
> > information about each field would have to be known. A short
> > description, it's content type, possible range information, etc.
>
> 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.
that's ok for me. look at uucp config file : sys (any other config file
will do the same). if you want to write an admintool you will have to
provide description, help texts, content type, range information,
logical structure etc. and the same way you would provide these
informations for data storred in the dtxtdb.
dtxtdb's job is to provide an interface, where you have no config file
like /etc/uucp/sys, and it should only store config information (and
maybe comments - they won't hurt).
dtxtdb and plain config files are the first layer.
the second layer would be a filtertool, that will
a) offer a standard way to provide informations like range, possible
valiues, logical structure etc.
b) can parse and write config files (offering a standart way to
implement that)
c) can will interact with a gui in a standart way ("here, list this menu :")
layer three would be a gui (ok, one with curses, one with x11, one with
cgi/web ...)
layer one is present (config files) or in work (dtxtdb).
layer three is not a big problem (perl&dialog can create the vc
interface, perl or tcl and tk the x11 one).
the problem is layer two (this layer has to understand e.g. uucp config sys)
and i have no idea how/who/when to do this. any volunteers ? (* :-) *)
> Andreas Jellinghaus <aj@dungeon.inka.de> said:
> > but : don't discuss it now. someone is working on a realy good textdb/
> > cfgtool/however-you-call-it, and i'm sure that he will do the right
> > thing. wait till it is released.
> Discuss it. I'd appreciate an open discussion.
ok. as you like. s.o.
comment about storing comments : it's enough if they are preserved in
the config files and are ignored. if you can supply comments with new
values, that woule be nice. but comments are not important.
> Andreas Jellinghaus <aj@dungeon.inka.de> said:
> > > Mark Baker:
> > > > Having your database seems like a reasonable idea, but it needs
> > to be plain > text which might be slow; a db file would be faster but
> > I want to be able to > change it in a text editor. As a compromise
> > it could use the same system than the sendmail aliases: The user make
> > changes in a plain text file (/etc/aliases), but the application
> > 'compiles' this file as a db database (/etc/aliases.db)?
>
> A database of some sort (e.g. tsearch dump) would be easy to implement,
> but I don't like the idea too much. May be later (OK, statting the text
> file first is a viable way in-between).
i don't like a database : we are talking about 100 config values or so
(maybe 200 if you can get rid of some old canfig files like
/etc/HOSTNAME, split config variables too much (like ethernet config -
IMO one line with the whole ifconfig command is the best way, you
shouldn't split 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: