TOOL debconf
debconf was created to resolve a recurring problem in Debian. All Debian packages unable to function without a minimum of configuration used to ask questions with calls to the echo and readcommands in shell scripts such as postinst and similar scripts. But this also means that during a large installation or update the user must stay with their computer to respond to various questions that may arise at any time. These manual interactions have now been almost entirely dispensed with, thanks to the debconf tool.
debconf has many interesting features: it requires the developer to specify user interaction; it allows localization of various strings of characters posted (all translations are stored in the templates file describing the interactions); it has different display models for presenting the questions to the user (text mode, graphical mode, non-interactive); and it allows creation of a central database of responses to share the same configuration with several computers... but the most important is that it is now possible to present all of the questions in a block to the user prior to starting a long installation or update process. The user can go about their business while the system handles the installation on its own, without having to stay there staring at the screen waiting for questions.
5.2.3. Checksums, List of Configuration Files
In addition to the configuration files mentioned in the previous sections, the control.tar.gz file in a Debian package contains others. The first, md5sums, contains the list of digital fingerprints for all of the package's files. Its main advantage is that it allows a tool such as debsums (which we will study in Section 14.3.3.1, “Auditing Packages: debsums and its Limits”) to check if these files have been modified since their installation.
conffiles lists package files that must be handled as configuration files. This involves a special handling, since configuration files can be modified by the administrator, and the changes are usually preserved during a package update.
In effect, in this situation, dpkg behaves as intelligently as possible: if the standard configuration file has not changed between the two versions, it does nothing. If, however, the file has changed, it will try to update this file. Two cases are possible: either the administrator has not touched this configuration file, in which case dpkg automatically installs the new version; or the file has been modified, in which case dpkg asks the administrator which version they wish to use (the old one with modifications, or the new one provided with the package). To assist in making this decision, dpkg offers to display a “diff” that shows the difference between the two versions. If the user chooses to retain the old version, the new one will be stored in the same location in a file with the .dpkg-dist suffix. If the user chooses the new version, the old one is retained in a file with the .dpkg-old suffix. Another available action consists of momentarily interrupting dpkg to edit the file and attempt to re-instate the relevant modifications (previously identified with diff).
GOING FURTHER Avoiding the configuration file questions
dpkg handles configuration file updates, but regularly interrupts these operations to ask for input from the administrator. This makes it less than enjoyable for those who wish to run updates in a non-interactive manner. This is why this program offers options that allow the system to respond automatically according to the same logic: --force-confold retains the old version of the file; --force-confnew wil use the new version of the file (these choices are respected, even if the file has not been changed by the administrator, which only rarely has the desired effect). Adding the --force-confdef option tells dpkg to use the default option when a choice is offered (in other words, when the original configuration file has not been touched), and only uses --force-confnew or --force-confold for other cases.
These options apply to dpkg, but most of the time the administrator will work directly with the aptitude or apt-get programs. It is, thus, necessary to know the syntax used to indicate the options to pass to the dpkg command (their command line interfaces are very similar).
# apt-get -o DPkg::Options::="--force-confdef" -o DPkg::options::="--force-confold" dist-upgrade
These options can be stored directly in the configuration for the apt program, rather than specified them each time on the command line. To do so, simply write the following line in the /etc/apt/apt.conf.d/local file:
DPkg::Options { "--force-confdef"; "--force-confold"; }
Including this option in the configuration file will allow it to also be used in a graphical interface such as aptitude.
GOING FURTHER Force dpkg to ask configuration file questions
The option, --force-confask requires dpkg to display the questions about the configuration files, even in cases where they would not normally be necessary. Thus, when reinstalling a package with this option, dpkg will ask the questions again for all of the configuration files modified by the administrator. This is very convenient, especially for reinstalling the original configuration file if it has been deleted and no other copy is available: a normal re-installation won't work, because dpkg considers removal as a form of legitimate modification, and, thus, doesn't install the desired configuration file.
5.3. Structure of a Source Package
5.3.1. Format
A source package is usually comprised of three files, a .dsc, a .orig.tar.gz, and a .debian.tar.gz or .diff.gz. They allow creation of binary packages (.deb files described above) for the program(s) from their source code, written in a programming language.
The .dsc (Debian Source Control) file is a short text file containing an RFC 2822 header (just like the control file studied in Section 5.2.1, “Description: the control File”) which describes the source package and indicates which other files are part thereof. It is signed by its maintainer, which guarantees authenticity. See Section 6.5, “Checking Package Authenticity” for further details on this subject.
Example 5.1. A .dsc file
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Format: 3.0 (quilt)
Source: zim
Binary: zim
Architecture: all
Version: 0.48-1
Maintainer: Emfox Zhou <emfox@debian.org>
Uploaders: Raphaël Hertzog <hertzog@debian.org>
Homepage: http://zim-wiki.org
Standards-Version: 3.9.0
Vcs-Browser: http://svn.debian.org/wsvn/collab-maint/deb-maint/zim/trunk?op=log
Vcs-Svn: svn://svn.debian.org/collab-maint/deb-maint/zim/trunk
Build-Depends: debhelper (>= 7.4.12), python-support (>= 0.8), xdg-utils, python (>= 2.5), libgtk2.0-0 (>= 2.6), python-gtk2, python-xdg, python-simplejson | python (>= 2.6)
Checksums-Sha1:
bd84fa5104de5ed85a49723d26b350856de93217 966899 zim_0.48.orig.tar.gz