Stephen Crowley <[EMAIL PROTECTED]> writes: > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: quoted-printable > > On Fri, Jan 22, 1999 at 12:58:35PM +0100, Brederlow wrote: >> Stephen Crowley <[EMAIL PROTECTED]> 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. >> >> Yes, there has been talk about. :) >> >> The best idea I saw was to have programms to ask questions for the >> script. Something like: >> >> dpkg-question --yes-no "Do you have a Gateway?" >> >> dpkg-question could then ask via slang, gtk or look into a >> database. The beauty of the aproach is that the install scripts >> don't have to be rewritten that much. >> > > Ack, that's no better than the way we do it now. Rrewriting install > script's shouldn't be a problem. It's going to have to be done > anyway. Imho, the scripts shouldn't have any user interaction at all > unless absolutely necessary, they should read variables from the > configuration manager. So the GUI isn't limited to a question/answer > type of interface.
dpkg-question is just the way to get config options. That doesn't mean that the user gets asked. dpkg-question should be given the priority of the question, the Variable to store the answere in and the default value. Depending on the existing database and the priority, dpkg-question can run without asking a single question. >>> The script would tell the frontend all the "variables" it has for >>> lack of a better name, the data types for each var (ip address, >>> string, number etc), default values and the valid range. You then >>> modify them in the configuration manager, their could two >>> frontends to it at least, one gtk based and one console based >>> (slang?). Then the program passes the var back to the script and >>> the script could possibly report invalid values back, if all goes >>> well it writes the confdata back to the file. Could there could be >>> an "apply" command to write the conffile and restart the daemon? >> >> The problem is that questions depend on the answeres of the previous >> questions. >> Take the example of a gateway: >> 1. Do you have a Gateway? >> 2. Whats the IP? >> >> You only want to ask for the IP, if there is a Gateway. You need a >> quite complex Syntax to allow for all sorts of dependencies. > > Well maybe not, the config manager would know that variable y may not exist > if variable x is a certain value. Who knows.. That would make the config manager understand a complete language. Thats not a good idea, since its difficult to implement and learn. >>> The generated config files should be easy to edit by hand, it >>> shouldn't be dependent on storing some codes in comments for the >>> script to parse or anything like that. >> >> I think the best way to represent a configfile would be as a shell >> script. >> ------------------------------------------------------------ >> #!/bin/sh >> # Config for Network >> >> # eth0 >> NETWORK_DEVIDE_0="eth0" >> NETWORK_IP_0="192.168.1.1" >> ... >> ------------------------------------------------------------ >> The config file can than have comments in it to make editing by hand >> easier. The install script would just source the config script and all >> variables would be set. Thats probably the easiest way to read in the >> config variables in the install script. >> > > Maybe the configuration data could be stored in a seperate file? I > don't know if that would be such a great idea though.. when the user > edits the file manually and then goes back into the configration > manager his changes would not have taken place. That's why I think > it would be better to have a script to the variable handling, it > could be smart enough to parse the user's changes. Of cause the config should be in a seperate file. The config manager or dpkg-question would try to read in the config file before asking questions about a package. Any values set in the config would overwrite the defaults in the deb file. Any changes made by the user would be read in when the config file is opened and then it would be locked and couldn't be changed until dpkg-question is done with it. >>> Just an idea, please let me know what you think. I need some input >>> before I start coding on this. >> >> Think about about a easy to understand syntax for dependencies of >> questions, maybe something like "make menuconfig/xconfig" does with >> the kernel config. > > Hmm, I haven't looked at the kernel config source before. I had a glance at it. Don't do it if you don't need it. :) May the Source be with you. Goswin