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

Re: Configuration frontend



On Sun, 24 Jan 1999, Aaron Van Couwenberghe wrote:
> On Sun, Jan 24, 1999 at 11:59:02PM +0100, Wichert Akkerman wrote:
> > Previously Aaron Van Couwenberghe wrote:
> > > Here's the simplest way to do it; just have the interpreter (yes, we're
> > > going to have to introduce a new scripting language for this, otherwise
<...>
> > I think I have to object here. Yes, it would make things a lot easier to
> > use a new language. But I'm really worried about making things hard for
> > developers.
<...>
> What I'm speaking of is the frontend's ability to handle logic. 

Why not have a package's preinst script send whatever data is
required to build a DB entry for that package, to a tool that decides
what to do with it (parse it, act on it, enter it into the DB, or ignore
it based whatever higher priority options are in force).  A postrm script
could then just send a request that the data be removed from the DB, the
tool recieving the request would decide on what gets done.

All the user needs to do is learn how to format the data so the tool(s) 
can use it.  Any logic is hidden away and has no chance of being divided
between the system and the package, this makes it trivial to change the
logic on a whim and chokes potential `I have dcfg 2v0, but the package
needs 1v666' problems down to that of format compatibility.

One non-technical benefit is that a straight forward configuration
description data set, should make it easy for anyone to add support
for a package that doesn't know about the configuration tools.  Another
is that the more independent the configuration system is of the package
management system, the better chance it stands of being picked up by
non-Debian users.  ;)


> We cannot
> simply treat the config database as a flat list of data slots to fill
> sometimes one variable even being relevant depends completely on other data
> that has been entered.

Can the database handle `multiple conditional defaults and options' for a
variable?  e.g., Where a variable's default and/or options change with
the configuration.  If so, then it should be fine (even if that means
using containers right off the bat).


later,

	Bruce


Reply to: