[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ next ]


dpkg technical manual
Chapter 1 - Quick summary of dpkg's external interface


1.1 Control files

The basic dpkg package control file supports the following major features:-


1.2 The dpkg status area

The "dpkg status area" is the term used to refer to the directory where dpkg keeps its various status files (GNU would have you call it the dpkg shared state directory). This is always, on Debian systems, /var/lib/dpkg. However, the default directory name should not be hard-coded, but #define'd, so that alteration is possible (it is available via configure in dpkg 1.4.0.9 and above). Of course, in a library, code should be allowed to override the default directory, but the default should be part of the library (so that the user may change the dpkg admin dir simply by replacing the library).

Dpkg keeps a variety of files in its status area. These are discussed later on in this document, but a quick summary of the files is here:-


1.3 The dpkg library files

These files are installed under /usr/lib/dpkg (usually), but /usr/local/lib/dpkg is also a possibility (as Debian policy dictates). Under this directory, there is a "methods" subdirectory. The methods subdirectory in turn contains any number of subdirectories for each general method processor (note that one set of method scripts can, and is, used for more than one of the methods listed under dselect).

The following files may be found in each of these subdirectories:-


1.4 The "dpkg" command-line utility


1.4.1 "Documented" command-line interfaces

As yet unwritten. You can refer to the other manuals for now. See dpkg(8).


1.4.2 Environment variables which dpkg responds to


1.4.3 Assertions

The dpkg utility itself is required for quite a number of packages, even if they have been installed with a tool totally separate from dpkg. The reason for this is that some packages, in their pre-installation scripts, check that your version of dpkg supports certain features. This was broken from the start, and it should have actually been a control file header "Dpkg-requires", or similar. What happens is that the configuration scripts will abort or continue according to the exit code of a call to dpkg, which will stop them from being wrongly configured.

These special command-line options, which simply return as true or false are all prefixed with "--assert-". Here is a list of them (without the prefix):-

Both these options check the status database to see what version of the "dpkg" package is installed, and check it against a known working version.


1.4.4 --predep-package

This strange option is described as follows in the source code:

     /* Print a single package which:
      *  (a) is the target of one or more relevant predependencies.
      *  (b) has itself no unsatisfied pre-dependencies.
      * If such a package is present output is the Packages file entry,
      *  which can be massaged as appropriate.
      * Exit status:
      *  0 = a package printed, OK
      *  1 = no suitable package available
      *  2 = error
      */

On further inspection of the source code, it appears that what is does is this:-

Eventually, it writes out the record of all the packages to satisfy the pre-dependencies. This is used by the disk method to make sure that its dependency ordering is correct. What happens is that all pre-depending packages are first installed, then it runs dpkg -iGROEB on the directory, which installs in the order package files are found. Since pre-dependencies mean that a package may not even be unpacked unless they are satisfied, it is necessary to do this (usually, since all the package files are unpacked in one phase, the configured in another, this is not needed).


[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ next ]


dpkg technical manual

$Id: dpkg-tech.sgml,v 1.3 2003/02/12 15:05:45 doogie Exp $

Tom Lees mailto:tom@lpsg.demon.co.uk