Re: Configuration frontend
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
> > it'll be ugly as heck) be able to toggle keys as active based on specified
> > criteria... We also need a rudimentary looping mechanism.
>
> 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. People already have to know sh-scripting, and learn a lot of
> Debian-specific tools. I know it took me quite a while to learn the
> intricasies of dpkg & friends. Do we really want to invent a new
> language? I fear we will loose a lot of developers then.
What I'm speaking of is the frontend's ability to handle logic. 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.
Now, you could do one of two things here. 1, keep certain pertinance
data with every key/value pair in the database, and other higher logic, or 2,
introduce a component tree that takes a backend to each package's
configuration.
To elaborate on number 2 (backend for each package), take the
'megicfilterconfig' script. It takes a possibly infinite list of printers,
the drivers associated with them, and the ports they are on.
The config script cannot decide ahead of time what variables it will
need. Hence, the frontend won't know what to ask. The only way to solve this
is to have a 'backend' which transparently gets the data as it is being sent
to the database, and automatically adds new keys.
I make it sound difficult. but it could be simplified substantially. each
backend could have an associated module that implements ask/query commands
for the language its implemented in. The ask command could put a new key into
the database (and assume that the frontend asks for user input, else default
value is assumed). The query command would then be called to get the data
part of the answer.
The query command would block until the key appeared in the
database. I don't quite know how this would be accomplished but anything is
possible.
Then, the postinst for each package would just have to know how to
query the database and write an appropriate config file. Nothing new here.
Another approach is just to force magicfilterconfig to use blobs
with proprietary tokens signalling begin/end of one of many values for a
key. This, however would force you to do things like this:
How many printers do you have? 3
for each printer, list the driver (.... show driver list here ...),
separated by semicolons: dj500;epson;dj550c
for each printer, respectively, list the device: /dev/lp1;/dev/lp2;/dev/lp3
And this is *bad*.
One final approach would be to severely limit interactive config's power.
This would make a) dpkg-admintool easy to write, b) package maintainers'
life simpler, and c) debian as a whole less powerful.
Wichert, others, do you have a more elegant solution to this problem? It is
a problem, and I think it should be thought about even before development on
the database implementation goes too far. I sure hope one is about somewhere
;)
--
..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org....
Berlin: http://www.berlin-consortium.org
Debian GNU/Linux: http://www.debian.org
Nullum magnum ingenium sine mixtura dementiae fuit. -- Seneca
Reply to: