Re: mass-installing Debian
Dean Carpenter <Dean.Carpenter@transamerica.com> 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
Reply to: