Re: Configuration frontend
>>>>> "B" == Brederlow <goswin.brederlow@student.uni-tuebingen.de> 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.
Reply to: