This is a bit long, so I'll summarize:
Debconf is a tool that packages can use to ask questions when they are
installed. It allows various frontends, from dialog, to gtk to web pages
to be used, and it also allows for non-interactive package installs, and
allows packages to ask questions all at once, before any of them are even
installed.
I'm been working on debconf for about 3 months and it's finally ready to
show to people. If you would like to try out debconf, simply add this line
to /etc/apt/sources.list:
deb http://va.debian.org/~joeyh/ debconf/
There are a few packages in there modified to use debconf. Good examples
include slrn, slrnpull, and sash. When you install these packages, they will
use dialog (by default) to ask the questions they need to ask.
Now, the long story.....
Currently, if a package needs to prompt the user for input, it just does,
using standard input and standard output to communicate with them. A few
packages use things like dialog for a user interface, while most use
bare-bones textual interfaces. There is little consistency between these
interfaces, since they are each written from scratch. They use different
methods to indicate default values, different ways to present lists of
choices, and even prompt in different ways when the user just needs to
hit enter after being shown a message. Many packages ask the user a series
of questions with no way to go back to a previous question, or to start
over.
Most packages that prompt do so in the postinst, and so the user has to
baby-sit an install, answering questions as they come up, and then waiting
for some more packages to be installed and some more questions to arrive.
There is no way to answer all the questions first and then let dpkg install
everything unattended, and so installs are a long, drawn out process.
Upgrades often take a long time as well, because many packages ask the same
questions over and over each time they are installed. Those that don't have
to store the user's last response somewhere, and they do this in a variety
of different, inconsistent, ways.
Moreover, there is no way to simply use default answers for all the
questions asked, if you're in a hurry or don't want to be bothered with
them, which has historically made the debian install a barrier to new users.
The traditional way of asking questions has made some specialized uses of
debian harder as well. Many experienced debian users would like to put
"apt-get update; apt-get upgrade" in a cron job, and have their system
upgraded periodically to unstable. People working on clusters or other
large-scale debian installations can't afford to answer the same questions
over and over again on each machine, and have hacked together various ways
around this.
Finally, several distributions have appeared recently, based on debian but
catering to inexperienced users. None of them want the user to see any
questions at all when they install, and they have used various hacks to
suppress the questions.
It seems clear that we need something better to replace the traditional
method of querying the user from a maintainer script. It needs to present a
consistent user interface to the user. It needs to be able to prioritize
questions so non-interactive installs are possible, as well as installs with
all questions asked, or only the most important ones. It needs to be able to
ask questions only once. And it would be nice if the questions could be
stored in a database on a central machine and sent out to other machines in
a cluster, so they need only be asked once for a whole cluster.
In fall of 1998, Wichert Akkerman came up with a specification for a
configuration management system that would address these needs. It was
refined on the debian lists over the next several months, and the final
specification is at http://www.debian.org/~wakkerma/config6/ .
The specification is very flexible, allowing for multiple different back-end
databases (using arbitrary database formats from SQL to plain text), that
can be layered together and accessed over the network or locally. It also
allows for a variety of user interfaces to be presented to the user. The
maintainer scripts communicate with the back-end and front-end using a simple
language.
Debconf is an implementation of this specification. At this point it consists
of a variety of front-end user interfaces (plain text similar to the
traditional method, dialog based, web, and GTK). It doesn't yet include the
flexible back-end database system from the specification. It is already fully
usable as a consistent way to configure packages.
As it stands now, debconf is usable along-side traditional packages, and
packages that use debconf will behave just like normal packages except they
use a consistent UI. Debconf also hooks into apt so if you use apt to
install several debconf-aware packages at once, the packages will prompt for
configuration information _before_ they are installed. An example is in
order -- this is using debconf's plain text front-end. This really can't
show off all of debconf's features, but it should give you the idea.
[EMAIL PROTECTED]:~> apt-get install sash lynx
Reading Package Lists... Done
Building Dependency Tree... Done
The following NEW packages will be installed:
lynx sash
0 packages upgraded, 2 newly installed, 0 to remove and 26 not upgraded.
Need to get 0B/1089kB of archives. After unpacking 2480kB will be used.
Lynx Configuration
------------------
Please enter the default URL to use if none is given when invoking lynx.
You must enter either a full URL (including the "http://";, etc.) or an
absolute pathname.
What is lynx's homepage? http://debian.org/
Sash Configuration
------------------
The best way to use sash is to install it as root's login shell. Currently
root's login shell is set to /usr/bin/zsh.
Should sash be root's login shell? [yN] n
Selecting previously deselected package lynx.
(Reading database ... 41813 files and directories currently installed.)
Unpacking lynx (from .../lynx_2.8.2-3.1_i386.deb) ...
Selecting previously deselected package sash.
Unpacking sash (from .../archives/sash_2.1-5.1_i386.deb) ...
Setting up lynx (2.8.2-3.1) ...
Update-menus[31963]: further output (if any) will appear in
/tmp/update-menus.31963
Setting up sash (2.1-5.1) ...
[EMAIL PROTECTED]:~>
I hope to upload debconf to unstable soon (once updated versions of menu and
apt that work with it are released).
--
see shy jo
