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... [EMAIL PROTECTED] [EMAIL PROTECTED] Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org Nullum magnum ingenium sine mixtura dementiae fuit. -- Seneca