RE: Configuration frontend
This sounds similar in principal to what I've been proposing for almost two years on this topic (even before this list was created). Can this be re-worded into multiple phases that we can start refining in discussion? It sounds like phase one is to have a configuration layer to interface with, and phase two is to provide a way to convert packages to interface to it. Even if this bit is totally transparent to the way it works now, we'll have achieved getting the abstraction in there to work the other phases. Can this be as simple as having an intermediate script simply take questions from a package installation script, present them to the user, get the user's response(s), and provide the answers to the package installation script?
The interaction between the package script and the intermediate script is the key bit. The rest can be further developed to do things like save state, provide the answers from a saved data store, etc. Further enhancements to the package scripts interface to the configuration layer can happen later to make it easier, etc. More sophisticated variable state management can come later as well.
If we can agree a very simple system to use as the configuration layer and a simple interface to a postinst script, we can work on converting packages to test with. Once that's done, we'll have something to show the other developers. It would of course be a good idea to fully flesh out the other phases so we can decribe the full project. It may be difficult to get buy in from people if all we had was this first bit and a bunch of loose ideas about what to do next.
Cheers,
Rich
----------
From: Mikolaj J. Habryn
Sent: Saturday, January 23, 1999 12:56 PM
To: debian-admintool@lists.debian.org
Subject: 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.
--
To UNSUBSCRIBE, email to debian-admintool-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: