Re: Proposal: Automatic query servicing for dpkg installation scripts
Andreas Degert <ad@papyrus.hamburg.com> wrote:
> Why are we asked questions when installing?
> 2) package configuration
>
> some packages need values for configuration parameters, like if you
> want xfig to use colors or if you want dotfile-xxx run faster by
> compiling the executable scripts.
I think that better examples could be had (in principle, xfig should
always use colors unless the display doesn't have enough color or unless
a mono command line switch is provided; dotfile-xxx should have a decent
default for executable scripts, perhaps patterned after emacsen or tex).
xmcd is a better example (and it also provides for configuration
independent of install, which is also an issue).
> 5) how to handle old config files on upgrade
>
> Examples are dpkg's "use old/new configuration?", or the question if
> to delete an unused old config file, or to convert a config file to
> the new format, or to repair it.
Note that it would be very helpful if there were some way of
providing some documentation to be supplied with this question.
> Goals:
>
> 1) scalability
> 2) separate the slow processes from the user interaction
> 3) allow to save messages and notifications that come up during
> installation and to view and analyse them later
> 4) don't ask questions more often than needed
> 5) generate a todo list for the administrator
> 6) allow to reconfigure a program
> 7) allow localization (different languages)
8) Administrator defined points of control.
At one extreme, the administrator wants the package system to keep
its hands off of carefully hand-tuned configuration files (we do this
fairly well right now, though there's probably room for improvement),
at the other extreme, the administrator wants to specify information
once and have it flow into a number of existing systems and new
installations (we don't even come close at the moment).
A typical installation would have one machine that the administrator
wants to be mostly auto-configured, and maybe eventually a second
machine which (as a starting point) should reflect the configuration
of the first machine.
9) System should be tolerant of human error.
If the sysadmin made a mistake it should be easy to go back
and fix it.
----------------------------------------------------------------------
> 3) periods during which packages are non-functional should be kept
> short
> non-functional could be "smail bounces all mail" or "xfig starts in
> monochrome mode instead of color mode". There appear to be
> different levels or importance.
Nit: for the case of smail, non-functional should be "smail
refuses to handle mail", and as I've already mentioned, I think
xfig should be color with the ability to adapt to b&w.
---------------------------------------------------------------------
> A database with answers solves the unattanted first-time installation
> of a package, but doesn't solve the upgrade. There should be a
> possibility to supply the new config files.
Er.. while I think I agree I'm really not sure what this means.
> Questions of a specific package might be answered in advance by
> loading it's "debian/questions file" from the .deb file, but then all
> questions will be presented, though maybe only part of them or none
> would be actually asked. One could try to use a script to present the
> sequence of questions, but because it's not the same context like when
> the package is actually installed, provisions would have to be taken
> for different scenarios during installation, and such a mechanism
> might get nasty to test.
Right, you want an "event-driven" user interaction model -- the
user is presented with information, which they may opt to change.
We need to solve this for text consoles (I'm thinking of a
scrollable region of "textual widgets"), and we ought to allow
for a TK retrofit.
--
Raul
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: