Brederlow <[EMAIL PROTECTED]> 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
files.
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
---
[EMAIL PROTECTED] [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
