Re: Configuration frontend
>>>>> 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.
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.
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).
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
--
@James LewisMoss <dres@ioa.com> | Blessed Be!
@ http://www.ioa.com/~dres | Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach
Reply to: