how about a meeting

[Joey Hess]

So BAD's not done anything since linuxworld. How about we have a meeting
next weekend? One possible meeting topic would be my debconf project. I've
attached a description of it below. I could talk about it, and also go into
details about using it in your packages for the developers present.

-- 
see shy jo


In this document, I'll explain how maintainer scripts in debian packages
have interacted with the user so far, the problems this causes, and the
things it prevents us from doing. Then I'll show how debconf can address
these problems.

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.

root@gumdrop:~> 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) ...

root@gumdrop:~>