Juhu, Fuer alle die schon immer drauf gewartet haben. Ein debian package fuer automatisiert installation oder zumindest um die installationsfragen zu umgehen oder eine einheitliche oberflaeche zu bieten bzw VOR der installation alle fragen zu stellen. Flo ----- Forwarded message from Joey Hess <joey@kitenet.net> ----- [...] X-Envelope-Sender: joey@kitenet.net Date: Fri, 17 Sep 1999 11:23:36 -0700 From: Joey Hess <joey@kitenet.net> To: debian-devel@lists.debian.org, debian-admintool@kitenet.net Subject: Announcing debconf, configuration management for debian Message-ID: <19990917112336.F20900@kitenet.net> Mail-Followup-To: debian-devel@lists.debian.org, debian-admintool Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0pre2i Resent-Message-ID: <5Bmz9.A.jXF.Ido43@murphy> Resent-From: debian-devel@lists.debian.org X-Mailing-List: <debian-devel@lists.debian.org> archive/latest/45087 X-Loop: debian-devel@lists.debian.org Precedence: list Resent-Sender: debian-devel-request@lists.debian.org Status: RO Content-Length: 6628 Lines: 145 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. 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:~> I hope to upload debconf to unstable soon (once updated versions of menu and apt that work with it are released). -- see shy jo -- To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org ----- End forwarded message ----- -- Florian Lohoff flo@rfc822.org +49-5241-470566 ... The failure can be random; however, when it does occur, it is catastrophic and is repeatable ... Cisco Field Notice