Re: Proposal: Automatic query servicing for dpkg installation scripts
Hi,
wouldn't it be better to not ask any question at all as part of the
core installation process? Sorry, this mail is long, I hope this
hasn't been covered extensively before (please supply pointers).
If I just install one package, it's ok that a lot of output is
produced, and maybe some questions are asked. But when I upgrade a
batch of packages or install a new system, it's not an optimal
solution.
I'd much prefer to enhance the installation process by dividing it
into two parts, where the first part is non-interactive and registers
information for the second, interactive part.
The registered information consists of log-output of the first part
(categorized by package and importance), and of a list of packages
with interactive configuration utilities (which might be simple
scripts). The user can browse through the logs and start the
configuration utilities of the newly installed/upgraded packages.
The list (package / associated configurator) should be kept, and just
a flag be cleared after done with first time configuration of the
package after install/upgrade (additionaly, it should be possible to
register one-time-queries, which will be deleted after they have been
run successfully). For packages that come without a configuration
program (like autofs), the user could be given the choice to just set
the flag or start an editor on the config file.
This requires that each package can be configured non-interactively
into a state that makes it usable for depending packages. Are there
any packages where this is impossible?
Removal/purging of packages can use the same mechanism, so when
purging a database package a script would be registered as
one-time-query. It deletes the datafiles on confirmation of the user
(this subject came up on the list recently). When the script has
finished successfully, it will be deleted (instead of resetting the
"not yet run" flag).
Ok, now the tough part ;-). When a package is installed for the first
time, it should be possible to provide a start configuration. But when
a package is upgraded, sometimes it won't work with the old
configuration, and the new start-configuration might not be what the
user wants. I just had this case when upgrading tetex, with the
extra quirk that somehow dpkg didn't ask which config files i want to
use (old/new), but instead used the old ones (dpkg but?), and the
postinst script runs into an error when using the old config file.
Would it be feasible that dpkg always installs the new config files
(which put the package into a sane state), but registers the old/new
questions, so that the user will answer it in the interactive part?
This way it would also be easy to enhance it with diff/merge
capabilities (for a 3-way merge we'd need the original old config
file, but better no additional feature-proposals in this mail..).
Packages that obey this new scheme could easily coexist with old
packages that don't. Of course if should be a goal of some future
distribution that no package directly requests input from the user or
just outputs to stdout / stderr.
What would have to be done (technically):
- Output categorization
categorize output like it's done by apt-get, for example prefix
I: for informational messages, E: for error, J: for junk ;-) etc.
- dpkg
- use prefix on all output
- redirect stdout/stderr to another fd (opened file, pipe)
- add prefix to script output without prefix; differentiate
between output to stdout and stderr (supply different prefix)
- package scripts
- change all direct output to prefixed output
- make a nice utility to view the logged output (or better, work on
apt ;-)
- Queries
- dpkg
- define a format and place for the package configurator list
(maybe a directory with one file per package,
/var/lib/dpkg/info ?)
- always use config files of package, register one-time queries
- don't ask questions
- when finished, start a program which lets the user start the
interactive package configurators (unless dpkg is told not to
start it)
- package scripts
- put the interactive part into a separate script and register the
script for installation part 2. There is a semantic change:
configurator scripts can be called more than once by the user;
maybe one should register one-time-queries in some cases
- devise a directory for configurator scripts that the maintainer
doesn't want to clutter /usr/bin
- a utility to register the pair (package/configurator)
- a program to display the list of packages with not-yet-run
configurators to the user and to start the configurators.
- a lot of things I didn't think of...
ciao
Andreas
PS.: I'm not on debian-policy (but debian-devel)
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: