Re: Announcing debconf, configuration management for debian

[Scott Barker <scott@mostlylinux.ab.ca>]

I have some suggestions. Does anyone care to comment?

1) Separate interactive and non-interactive installation scripts. I suggest
   that the current debian install scripts should contain *only*
   non-interative functionality, such as running ldconfig, update-rc.d, etc.
   *All* interactive functionality should be moved into a separate config
   script. Perhaps a new control field can be added to the debian packaging
   system. For example:

           ConfigScript: /usr/sbin/sendmailconfig

   When dpkg installs a package, it runs the various (non-interactive) scripts
   as it does now, then if a ConfigScript is defined, it can run that. Or,
   running the config script can be deferred to a later time, or done before
   the package is unpacked (of course, the config script would need to be
   unpacked even if unpacking the rest of the package was deferred).

   This way, debconf can still be utilized by the ConfigScript, and an extra
   benefit is that users will have a config program they can easily look up
   and run to reconfigure any package. In fact, we could have an option like
   --reconfigure for dpkg so a user could even skip looking up the name of the
   ConfigScript

2) Add one more level of configuration to debconf: configure new parameters.
   This would help immensely when upgrading clusters of workstations. An
   administrator can be notified of all configuration changes when upgrading a
   package on one workstation, but once the values of those parameters have
   been set on that workstation, other workstations can inherit them during
   their upgrades without prompting.

3) Since no database back-end is yet implemented, perhaps we need nothing more
   than a config file called:

        /etc/debconf/<package>

   In a .deb package, a default configuration could be provided in this
   file. After debconf runs, all options in this file could be updated based
   on the user's input. The administrator could then do a dpkg-repack on the
   package, and use the modified package on the rest of the cluster. While not
   as convenient as some kind of network-distributed database, this approach
   would at least allow debconf to be deployed sooner rather than later as
   part of the base Debian system. The config file mentioned above would
   probably have to be handled differently than the current definition of
   config file within a debian package, such that new options can be merged
   into an existing configuration. Also, it would be nice to be able to embed
   a bit of perl into the config file, so you could do things like:

        $lynx_home_page = "www.`dnsdomainname`";


-- 
Scott Barker       scott@mostlylinux.ab.ca
Linux Consultant   http://www.mostlylinux.ab.ca/scott

Looking for a husband? Know anyone looking for a husband? Well, I'm looking
for a wife. See http://www.mostlylinux.ab.ca/scott/wife.shtml

Want a good deal on a personal computer in Calgary, Alberta, Canada?
Visit http://www.mostlylinux.ab.ca/scott/computers.shtml

[ Unsolicited commercial and junk e-mail will be proof-read for US$100 ]

"Silent gratitude isn't very much use to anyone."
   - G.B. Stein