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 [EMAIL PROTECTED]
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
