Dean Carpenter <[EMAIL PROTECTED]> writes: > I've been thinking a bit about the need for mass-installations. Having > done a few of them, it gets to be a tad tedious ... > > Currently, the preinst and postinst scripts ask the user questions, and > make changes according to the responses. Instead of that, we need a > general service script that processes a package-specific file containing > questions and answer-variables. The results of this get appended to > an installation response file that each package can source to retrieve > the answers it needs. Hrmm, got that ?
Have a look at ftp://mirjam.informatik.uni-tuebingen.de/pub/debian/proposal.txt and the deb packages in the same directory. Its a proposal about how to improve configuration of debian system. Non-interactive or pool installations is one main concern for this proposal. Also it introduces levels for questions, so unexpirienced users don't have to answere al questions. Also it provides a easy way for several interface (console, whiptail, menuconfig, X, html). It will also be possible to configure some packages as user, e.g. fvwm. Another nice feature I'm working on, which is not yet in the proposal, is a better way of handling changes in config files during package updates. The script will be able to detect not only unchanged scripts, but also detect what options are changed by a user or by the administartor and if an option is set to the package default it can be savely updated to the new default. If an option is not the package default you can eigther keep your selection or view the changes made in the package default, depending on how you configured the frontend. > Now during installation, the exim preinst and postinst scripts would > source the install-response file, creating the variables with the > responses they need. At this point, it's just as if they've asked the > questions and retrieved the user responses. If a particular response > variable doesn't exist in the install-response file, the script can > still prompt just like normal, though this ruins the effect. But what about something like the windowmanager files? They aren't shell scripts, so you would have to have a config.sh file that gets parsed by postinst and gets translated to the windowmanagers config file. But what if something has changed in the windowmanagers config file? All changes would be lost or the config.sh file would be useless. It's one of the main drawbacks of yast that it will undo any changes you made to configfiles, because it has its own database, which gets translated into config files. My proposal takes a different aproach: Any package can provide "configure.setvar", "configure.getvar" and a few other files. configure.setvar will be used to store an option into the packages config file and config.getvar will be used to extract an option. Those files are binaries (or scripts) written in any language and if nonexistent default bash functions will be used and a shell script as configfile will be assumed. > Where dselect has the list of packages to be installed and is waiting for > the user to select "Install", it can run the service script to pre-ask > all the config questions. Once that's done, run the normal install > and the user can walk away. Or ask the user while its unpacking or downloading other packages. Thats something for the new dpkg thats discussed here at great detail. > Even better is combining this with a pre-selected list of packages and > a pre-built install-response file. > > Heh heh, the mechanics of all this is an exercise left to the reader :) Or have a look at the site mentioned above. Try the qvwm package. It uses the rather ugly looking dpkgconfig to ask for certain setting for the windowmanager config and dpkgconfig is not yet fully written, but useable. May the Source be with you. Goswin
