Re: Proposal: Automatic query servicing for dpkg installation scripts
Hi,
I've looked throught the previous discussions in this thread and tried
to review them in a slightly broader scope. The section about the so
far proposed solutions is nearly empty yet :-)), but it's late now and
I want to get this out as a first draft and maybe get some feedback.
ciao
Andreas
PS: I've taken this away from debian-policy, is there a better forum
for it than debian-devel? (maybe debian-admintool?)
=============================
Why are we asked questions when installing?
-------------------------------------------
Asking questions during installation serves multiple purposes. I did a
survey of all packages installed on my notebook (not very thoroughly,
see appendix), and came up with the following categories:
1) notification
packages want to make sure a administrator reads a certain
information, and require the administrator to hit a key after
reading.
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.
3) system configuration
some parameters are asked during package installation now, but are
really parameters (also) defining system behaviour, not the inner
working of the package. Examples are setting defaults for mime
handlers or window managers.
4) confirmation to proceed with a dangerous operation
Examples are removing modutils or stopping the display
manager.
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.
Question in all of these categories can be conditional; they are not
asked in all cases.
Which deficiencies does this current scheme have?
-------------------------------------------------
1) notification
This is sort of a mis-use of asking question, it's a consequence of
a lot of messages running over the screen during installation and
having to stop the flow for important messages. This method has two
drawbacks: it defeats unattended installs, and requires the
administrator to memories all those important notices (like
"attention, please check config file /etc/xxx after install).
2) package configuration
- no unattended install
- the lengthy process of unpacking, and running of non-interactive
postinst scripts is intermixed with the questions of comparatively
few interactive scripts.
- software with complex configuration can't be configured with a
simple chain of questions. So it's left unconfigured, but the
configuration of these packages isn't in any way connected with
the install process.
- it doesn't scale -- installing a batch of identical or similar
machines means answering those questions over and over again.
- no possibility to predefine a configuration
- the configuration process can't be repeated; the only (supported)
way is to reinstall the packages (is this correct?). For example,
if I decided at installation time to use the color version of
xfig, but want to change it to the monochrome version later. Of
course, currently this can be provided by writing a separate
configuration program and using it in the postinst. Drawback:
admins have remember each of these config programs (like
smailconfig).
3) system configuration
like 2), additionally
- questions are asked more often than needed. E.g., when installing
n dictionaries, the default dictionary has to be specified n-1
times instead of once.
4) confirmation to proceed with a dangerous operation
like 2), only this is more difficult to solve (and there's no point
in repeating)
5) how to handle old config files on upgrade
like 2), but different from 4).
Think positive :-) : goals of the new handling
------------------------------------------------
Maybe some of these goals have their origin in existing implementation
ideas, but at least it's a start... This is a broader scope than the
originally intended query service, but often things are interrelated
and one has to look at all consequences before deciding for a specific
design.
Goals:
1) scalability
It should be possible to answer questions once, and then install on
several system using these anwers. It should also be possible to
overwrite some parts of the global configuration for the local
machine (e.g. by a hierarchical scheme).
2) separate the slow processes from the user interaction
Unpacking of packages and running of non-interactive scripts takes
a lot of time; this should be separated from answering questions,
which halt the installation.
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
this is meant for a single install, not related to scaling
5) generate a todo list for the administrator
It should hold information about things to look at or programs
still to configure. It should be possible to post-process this
information, to present it as a list of items from which
configuration programs can be directly started (or to open the
affected config files with an editor if there's no special
program).
6) allow to reconfigure a program
7) allow localization (different languages)
Restrictions:
1) compatible with the old scheme
old packages should not cease to work
2) as few as possible modifications to important components like dpkg
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.
Proposed solutions
------------------
Due to time constrains, the section is nearly empty yet (though there
have been several proposals), but i'd like to comment on a few points.
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.
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.
APPENDIX
Installation Services
=====================
I tried to come up with a list of excisting debian installation
services, maybe it helps in reviewing some of the ideas. This isn't
complete in any way, and some entries, like "set default window
manager", are not available as a separate script (yet?).
registration
-------------
install-info
install-menu
update-inetd
update-passwd
update-rc.d
install-mime
setting default handlers
------------------------
update-alternatives
install-mime (*, setting priorities)
update-ispell-dictionary (*)
default window manager (*)
default boot kernel (*, not yet defined)
(*) interactive
interactive packages on my notebook
===================================
401 packages, 37 interactive (not counting packages using install-mime
and update-ispell-dictionary)
only confirmation (13 packages)
-------------------------------
- kernel-header-2.0.32
- cruft
- tetex-base, tetex-bin, tetex-extra
- anacron
- dosemu (postinst and preinst)
- fvwm2
- libc5
- login
- lprng
- motifnls
- netstd preinst
- sysklogd
- sysvinit
register mime
-------------
- acroread
- bplay
- gv
- imagemagick
- lynx
- metamail
- mime-support
- playmidi
- sox
register ispell dictionary
--------------------------
- iamerican
- ibritish
- igerman
register as default
-------------------
- xserver-s3 (default xserver)
- wenglish, wgerman (default dictionary)
- kernel-image-xxx (default boot kernel)
configuration (14 packages)
---------------------------
- inewinn (complex config)
- minicom (simple config: ask for meta key)
- dhcpdc (simple config)
- gpm (simple config)
- ircii (simple config, confirm to proceed)
- lynx (simple config)
- pine (simple config)
- playmidi (simple config)
- xfig (simple config)
- xntp3 (simple config)
- xmcd (configure now? -> start xmcdconfig)
- dotfile-xxx (confirm: bytecompile now - else later)
- xbase (start xdm at boot time, start xdm now)
- kernel-image-xxx (complex config)
confirm to delete/move/convert/correct old config files
-------------------------------------------------------
- ppp (remove unused config file?)
- netbase preinst (disable chargen?)
- svgatextmode (delete/move old config files?, new location)
- lyx (delete old config file?)
- modutils (convert old config file)
- dpkg (confirm proceed repair runlevels, repair info)
confirm proceed with dangerous operation
----------------------------------------
- kernel-image-xxx
- prerm (confirm to remove running image)
- postinst (confirm message, confirm proceed)
- sudo (confirm: problems when gid 27 isn't free)
(btw., reads /var/lib/dpkg/status)
- dpkg preinst (confirm proceed if may loose config changes)
- kdebase preinst (stop display manager?)
- modutils prerm (confirm remove)
- xbase preinst (stop xdm/xfs now?, save old config files?)
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: