Re: Configuration frontend
James LewisMoss <dres@ioa.com> writes:
> >>>>> On 22 Jan 1999 12:58:35 +0100, Brederlow <goswin.brederlow@student.uni-tuebingen.de> said:
>
> Brederlow> Stephen Crowley <crow@debian.org> writes:
> >> Has there been any talk of a central configuration frontend? I was
> >> thinking it'd be really nice to have something where each package
> >> registers a script, similiar to how the menu system works.
>
> Brederlow> Yes, there has been talk about. :)
>
> Brederlow> The best idea I saw was to have programms to ask questions
> Brederlow> for the script. Something like:
>
> Brederlow> dpkg-question --yes-no "Do you have a Gateway?"
>
> Specifying that a configuration should be done in a postinst (or
> elsewhere) is a good thing. This isn't the best. You need to be able
> to group everything together so that all questions are asked at once,
> and you need a more complex question setup than one script call should
> reasonably give you.
Yep.
> Brederlow> dpkg-question could then ask via slang, gtk or look into a
> Brederlow> database. The beauty of the aproach is that the install
> Brederlow> scripts don't have to be rewritten that much.
>
> This is good, but it's got to be some separate data file describing
> what the questions are with front ends that parse that data file.
That would mean to invent a new language to write those datafiles.
> Also useful are two backends (could be same script/binary, but
> separating them by function at least theoretically is a good idea
> imo). The first reads the current system configuration. The second
> writes it.
>
> So the order of processes
>
> <backend reader> -> <data file/pipe describing current state> -> <front end>
> <config file describing what possible states are good> -^
>
> <front end> asks questions and creates another data file/pipe
> describing status to set and passes it to <backend writer>. There
> needs to be provisions for sections of the current status data that
> are not touched but instead passed back to the writer backend as near
> exactly as they were created (don't want to strip or mess with
> comments in the code. That drives me nuts).
>
> Brederlow> The problem is that questions depend on the answeres of
> Brederlow> the previous questions. Take the example of a gateway:
> Brederlow> 1. Do you have a Gateway?
> Brederlow> 2. Whats the IP?
>
> Yup. That's why the config file describing states has either got to
> be 1) a very complex config file or 2) able to be a separate binary of
> some sort that actually drives whatever frontend is there. So best
> option is to have 3) either a fairly simple good in 90% of the cases
> config file or a binary that actually drives the front end (with some
> standard interface between the binary and the frontend).
A shell/perl/python script driving dpkg-question would be fine I
think. I opt for shell scripts, because python isn't very common and
nobody can read perl scripts.
> Brederlow> I think the best way to represent a configfile would be as
> Brederlow> a shell script.
>
> Really not expressive enough.
>
> Brederlow> The config file can than have comments in it to make
> Brederlow> editing by hand easier. The install script would just
> Brederlow> source the config script and all variables would be
> Brederlow> set. Thats probably the easiest way to read in the config
> Brederlow> variables in the install script.
>
> Easy maybe, but not best IMO.
>
> Dres
I though about it some more. First some goals I would like to achive
with a new configuration tool:
1. Don't stop downloading/unpacking because of questions.
2. Cloneing of a System to a pool must be possible.
3. Ask as few questions as possible, unless wanted. (levels of
questions)
4. Allow for reconfiguration.
5. Remember what was chosen by the user and what by dependencies.
6. The way questions are ask must be swappable (shell, dialog, X, ...)
7. Answering Questions should be possible while installing (multithreaded).
If you can think of more, add them.
And now a proposal to achive those more or less:
Each package has two fairly identical installation script, one for
asking questions and one for reacting on them. The first one would be
a dry run of the second, while the second can't ask, but reacts on the
configfile generated by the first.
The first script uses an abstract interface to ask questions, maybe like
dpkg-question --type "Variable for storage" "Text" "Level" "Default"
e.g.:
dpkg-question --yes-no "GATEWAY_YES_NO" "Do you have a Gateway?" "allways" "No"
Depending on the return of dpkg-question the script can behave
differently. Every Question (and esspecially its answere) are recorded
into eigther a database or a shell script.
The second script should have an identical structure to the first, so
that equal behaviour is ensured. The script would interact with the
recorded answeres from the first script and only in case of an error
it would need the intervention from the user. The answere should be
extracted from the database (which might just mean sourcing the config
file).
The first goal should be easy to achive, since its mostly achived
already.
Cloneing a System would mean copying the database or all config files
to another system or exporting them to the pool.
The third goal would be achived by dpkg-question. The Level and
Default given by the commandline can be used to skip questions.
Reconfiguration, the forth goal, is already possible, but not yet
used. The install script would just be restarted. The answeres given
the last time can be used by dpkg-question to present a better
default.
The fifth goal is a change to dpkg or apt. If I install freeciv-xaw3d
and need the xaw3d library only for it, i want to remove the xaw3d
library when removing freeciv-xaw3d. dpkg should inform me that all
Packages depending on xaw3d are purged and ask whether it can be
removed or not. A simple reference counting of dependencies would be
enough. Any Package that has a count of 0 can be purged.
The sixth goal is achived by the abstract dpkg-question (or
similar). The install scripts don't have a clue on how the questions
are asked.
The seventh goal is a matter on how dpkg is changed. Using several
threads for downloading/instaling, asking questions and configuring
achives that. As soon as a package is unpacked, the question script
can be run, as soon as that is done, the second script can be run.
Well, thats a rough sketch of the idea I have in mind.
May the Source be with you.
Goswin
Reply to: