>>>>> "B" == Brederlow <[EMAIL PROTECTED]> writes:
B> Think about about a easy to understand syntax for dependencies B> of questions, maybe something like "make menuconfig/xconfig" B> does with the kernel config. Ack! I rather suspect that we're all trying to do far too many things at once. There are several problems that we need to address that are almost entirely orthogonal in implementation. o Changing packages to interface to a configuration layer rather than just the user. This one is fairly simple, right? Does anyone have a problem with dpkg-question or dpkg-config or whatever being used to do *all* user interaction? Is there any situation that cannot be covered by the use of 'dpkg-config variablename' and arbitrary data about variablename being provided elsewhere? o Making a more flexible configuration language that will simplify the task of making configuration scripts. This would be nice, but it isn't urgent. Why not? Because if we don't do this step, but do all the others, we will lose no functionality. Think about it - currently packages have working configuration tools. They may not be pretty, they may have caused much hair-rending to their maintainers, but they *do* exist. We already have all of the mechanisms in place for including this - postinsts are executable, after all, so just write a new interpreter that's tailored toward this task. o Distributing configuration and saving state so that questions don't need to be asked multiple times. This is the cute one, but it also is entirely separate from the rest. If we implement a dpkg-config system, then querying a database for the answers is just another implementation of dpkg-config, alongside gtk, slang, etc. I have a certain amount of experience with jumping headlong into huge projects. It doesn't generally wind up working the way you imagine it to in the heat of the moment :) We have a very simple incremental path that we can follow to basically create a complete package-configuration-system-from-hell incrementally. And yes, some of the stages will require changes to dpkg, or deploying large amounts of yet-to-be-written software. However, if we try to solve all of the problems in one swell foop it will delay even the simple things. m.