PROPOSAL: configuration of packages
Heres my proposal about how a more userfriendly and/or automatik
configuration should be done. Its still a draft so feel free to rip it
apart. :)
My proposal consists of several parts:
1. Changes to dpkg
2. configure
3. configure.set_var, configure.get_var and other spezialities
4. dpkg-question
5. Configuration frontends
6. dpkg-test
7. dpkg-action
8. dpkg-hook
1. Changes to dpkg
------------------
dpkg must call the configure script, which will be kept in the
control.tar.gz along with postrm and so on.
2. configure
------------
The configure script will be included in the control.tar.gz file. It's
syntax is a subset of bash and is kept easy to allow for easy
parsing. It's function is similar to the config files used by the
kernel to generate the menuconfig and xconfig menus, but it should be
executable by itself. All interactions with the user are kept inside
the configure file and are through "dpkg-question". Any tests done on
the installed system must be through dpkg-test and any changes
inflicted during configuration through dpkg-action. Interactions with
other packages are done via dpkg-hook. Apart from that if
clauses, while loops and maybe switch/case statements are allowed.
3. configure.set_var, configure.get_var and other specialities
--------------------------------------------------------------
configure.set_var and configure.get_var might be any kind of
executable, but should be bash or another generally present scripting
language. Their purpose is to read and save configuration options from
the package datafile. If one or both aren't present, a default is
provided. This feature is ment for packages that have their own config
files and can't work with shell scripts, e.g. (windowmanager,
apache,...).
There are also several enviroment variables that can be set to change
the way dpkg-question will behave:
<package>_CONFFILE=<the package's configuration file>
<package>_DEFFILE=<the package's default configuration>
<package>_USERFILE=<the package's configuration file for the user>
Those three variables will be used by dpkg-question for calls to
get_var and set_var, so that the correct file in the correct place is
used. The <package>_USERFILE will be treated relative to the users
homedir, e.g. ".emacs" would be translated to ~<user>/.emacs.
CONFIG_USER_LEVEL=<level>
CONFIG_NON_INTERACTIVE=<yes/no>
CONFIG_FROM_DEFAULT=<yes/no>
CONFIG_...
Those variables (and probably more will come) will select how
interactive dpkg-question will be. Through this you can copy a
configuration from one system to another and reconfigure it non-
interactive or install a pool via a database kept on one
server. Configuration frontends will use those variables to tell that
packages have already been preconfigured by them.
4. dpkg-question
----------------
dpkg-question handles all interactions with the user. It is also used
to layout the menustructure used for menuconfig or xconfig like
menus. A normal invocation of dpkg-question has the following form:
dpkg-question <question-id> <level> <type> <text> <type specific parameters>
e.g. dpkg-question QVWM_RESTART_ON_FAILURE 2 --yesno "Should qvwm restart on failure?"
The type determines what the question will actually look like and the
result will be stored in the question-id (or whatever method
configure.set_var uses if present). Possible types at the moment are:
--yesno Boolean question or checkbox on menus
--int Any integer, upper and lower limit can be set
--posint Any positive integer, upper and lower limit can be set
--real Any number, upper and lower limit can be set
--ip A valid IP adress, hints can be given for e.g. netmasks
--color A color of the form #xxxxxx or its name
--string Any text, a pattern can be given
--file Any file
--directory Any directory
--e-mail A valid email adreess
--url A valid url
--selection Select one from a group
--error Notify the user of an error
--msg Tell the user of something
5. Configuration frontends
--------------------------
Without anything extra the configuration will be like "make config"
for the kernel. Just one question after another. But much more is
possible and will be normal behaviour. Writeing a frontend should be
fairly easy, because of the structure of the configuration scripts.
The following frontends are under developement or are planed:
dpkg-menuconfig will parse the configure files of all packages (or
only the new packages or ...) and generate a menu hirachy from
that. If you want to know what it looks like, do a "make menuconfig"
with the kernel.
dpkg-htmlconfig will generate a html interface via cgi scripts.
Together with apache or other web server remote configuration
can be done.
dpkg-cloneconfig can save or restore the complete config of all
packages. An option to clone a configuration from a server should be
easy to do. Another option would be to generate a .deb file that
contains the current configuration and will install that and all
packages needed when installed itself.
6. dpkg-test
------------
dpkg-test <program> <parameters> will run the <program> with the
<parameters> and return the return value of the program. dpkg-test can
be ignored, but its there for the parser to detect that they must run
that test while building the menu.
7. dpkg-action
--------------
dpkg-action <program> <parameters> will run the <program> with the
<parameters>. This is also just a keyword for any parser to show that
the command must not be evaluated. dpkg-action should be used seldomly
in configure scripts. Normaly set_var will do any changes to config
files. The main purpose is to be used for starting and stopping deamons.
8. dpkg-hook
------------
Via dpkg-hook configuration dependencies can be notified to the system.
Possible cases are that this packages changes the configuration of
another package and thus that package must be reconfigured (like the
menu system) or this packages must be reconfigured when another
package is installed or removed. If other scenarios come up, they will
be added here.
Well, thats it so far. Additions, changes and comments welcome.
May the Source be with you.
Goswin
PS: Wow, you read a mail longer than 100 lines. :)
Reply to: