Re: Configuration file update behaviour change options

[Raul Miller <rdm@tad.micro.umn.edu>]

I think we've nearly reached the edge of our current user interface
paradigm for configuration file handling by dpkg.

I think the next step would be to craft an interactive tool for
handling dpkg post-unpack processing.  This (these) tool(s) would have
to have intimate knowledge of the dpkg internals and thus ought to be
put in the dpkg source package once they're out of alpha.

The first stage of designing such a tool would be collecting
wishes/desires/random thoughts about how it "ought to be".  Here's a
start:

(1) sufficient embedded knowledge to help the new sysadmin make
intelligent decisions.
(2) configurable to support local trans-package system administration
decisions.  For example: 
  (*) delete all non-local time zone files after configuring the
  timezone package
  (*) uncompress all files in /usr/doc after any package installation
  (note: ugly implications here)
  (*) warn me if smtp service is ever disabled after any package
  installation run.
(3) all processing should be designed to be re-startable, especially
after unexpected program termination.
(4) keep an eye on other systems' installation support for ideas
(e.g. Microsoft, Apple, ...)


I don't propose writing this -- I just wanted to get the idea out of
my head so I could delete a message from my mailbox.  I think a lot of
light would be shed if the present discussion of dpkg enhancements
were considered as potential for inclusion of such a hypothetical
design.

To do this right, maybe we need to hunt down and find a
window-gui-interaction sort of tool which generates script-style
commands as an intermediate before performing significant actions?
[I've heared mention of such a thing, but I've not pinned it down.]

-- 
Raul