[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Non-interactive install proposal

Brederlow <goswin.brederlow@student.uni-tuebingen.de> writes:

> A good way to start would be to seperate the unpacking and
> installation from the configuration.
> dpkg should start one thread to extract a package, when a package is
> done a second threat is signaled and the next is extracted.
> The second thread configures the package. If any question is to be
> asked, the controll is given to a third threat and the next package is 
> configured.
> The third thread pops up the question. As soon as the user has
> answered the package is send back to the second thread to continue
> installation. The third thread could search a database instead of
> asking the user and only ask for unknown questions.

On slow systems and systems with little memory, this will dramatically
slow down the process. I once installed a 1.3.1 on a 486/33 and was
very annoyed by the scanning databases step while running dselect
(because it was on an install party).
So please take performance into consideration, too.

I suggest:

As every package knows best, what questions to ask and which config it
relies on, allow a script with a defined interface (sh, perl, whatever
the maintainer likes and what language is available in a base system).

The script will ask the necessary questions and prepares configuration

This script can be given information, how packages it depends on have been
configured, and gives the configuration information back to the
database (Which data to pass is determined by a config file entry).

The {post,pre}inst script now only has to extract the config info and
genarate the actual configs. Administration of a farm now consists of
distribution of the database and localization of the database).

If we then get this interfaced to COAS all will be well. :-)


Jens.Ritter@weh.rwth-aachen.de   grimaldi@debian.org
Key ID: 2048/E451C639 Jens Ritter
Key fingerprint: 5F 3D 43 1E 24 1E CC 48  1E 05 93 3A A7 10 73 37 

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: