The basic dpkg package control file supports the following major features:-
5 types of dependencies:-
Pre-Depends, which must be satisfied before a package may be unpacked
Depends, which must be satisfied before a package may be configured
Recommends, to specify a package which if not installed may severely limit the
usefulness of the package
Suggests, to specify a package which may increase the productivity of the
package
Conflicts, to specify a package which must NOT be installed in order for the
package to be configured
Each of these dependencies can specify a version and a depedency on that
version, for example "<= 0.5-1", "== 2.7.2-1", etc. The
comparators available are:-
"<<" - less than
"<=" - less than or equal to
">>" - greater than
">=" - greater than or equal to
"==" - equal to
The concept of "virtual packages", which many other packages may
provide, using the Provides mechanism. An example of this is the
"httpd" virtual package, which all web servers should provide.
Virtual package names may be used in dependency headers. However, current
policy is that virtual packages do not support version numbers, so dependencies
on virtual packages with versions will always fail.
Several other control fields, such as Package, Version, Description, Section,
Priority, etc., which are mainly for classification purposes. The package name
must consist entirely of lowercase characters, plus the characters '+', '-',
and '.'. Fields can extend across multiple lines - on the second and
subsequent lines, there is a space at the beginning instead of a field name and
a ':'. Empty lines must consist of the text " .", which will be
ignored, as will the initial space for other continuation lines. This feature
is usually only used in the Description field.
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:-
available - this file contains a concatenation of control information from all
the packages which dpkg knows about. This is updated using the dpkg commands
"--update-avail <file>", "--merge-avail
<file>", and "--clear-avail".
status - this file contains information on the following things for every
package:-
Whether it is installed, not installed, unpacked, removed, failed
configuration, or half-installed (deconfigured in favour of another package).
Whether it is selected as install, hold, remove, or purge.
If it is "ok" (no installation problems), or "not-ok".
It usually also contains the section and priority (so that dselect may classify
packages not in available)
For packages which did not initially appear in the "available" file
when they were installed, the other control information for them.
The exact format for the "Status:" field is:
Status: Want Flag Status
Where Want may be one of unknown, install,
hold, deinstall, purge. Flag may be one
of ok, reinstreq, hold, hold-reinstreq.
Status may be one of not-installed, unpacked,
half-configured, installed, half-installedconfig-files, post-inst-failed, removal-failed. The
states are as follows:-
not-installed
No files are installed from the package, it has no config files left, it
uninstalled cleanly if it ever was installed.
unpacked
The basic files have been unpacked (and are listed in
/var/lib/dpkg/info/[package].list. There are config files present, but the
postinst script has _NOT_ been run.
half-configured
The package was installed and unpacked, but the postinst script failed in some
way.
installed
All files for the package are installed, and the configuration was also
successful.
half-installed
An attempt was made to remove the packagem but there was a failure in the prerm
script.
config-files
The package was "removed", not "purged". The config files
are left, but nothing else.
post-inst-failed
Old name for half-configured. Do not use.
removal-failed
Old name for half-installed. Do not use.
The two last items are only left in dpkg for compatibility - they are
understood by it, but never written out in this form.
Please see the dpkg source code, lib/parshelp.c,
statusinfos, eflaginfos and wantinfos for more
details.
info - this directory contains files from the control archive of every package
currently installed. They are installed with a prefix of
"<packagename>.". In addition to this, it also contains a file
called <package>.list for every package, which contains a list of files.
Note also that the control file is not copied into here; it is instead found as
part of status or available.
methods - this directory is reserved for "method"-specific files -
each "method" has a subdirectory underneath this directory (or at
least, it can have). In addition, there is another subdirectory
"mnt", where misc. filesystems (floppies, CDROMs, etc.) are mounted.
alternatives - directory used by the "update-alternatives" program.
It contains one file for each "alternatives" interface, which
contains information about all the needed symlinked files for each alternative.
diversions - file used by the "dpkg-divert" program. Each diversion
takes three lines. The first is the package name (or ":" for user
diversion), the second the original filename, and the third the diverted
filename.
updates - directory used internally by dpkg. This is discussed later, in the
section Updates, Section 3.1.
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:-
names - One line per method, two-digit priority to appear on menu at beginning,
followed by a space, the name, and then another space and the short
description.
desc.<name> - Contains the long description displayed by dselect when the
cursor is put over the <name> method.
setup - Script or program which sets up the initial values to be used by this
method. Called with first argument as the status area directory
(/var/lib/dpkg), second argument as the name of the method (as in the directory
name), and the third argument as the option (as in the names file).
install - Script/program called when the "install" option of dselect
is run with this method. Same arguments as for setup.
update - Script/program called when the "update" option of dselect is
run. Same arguments as for setup/install.
DPKG_NO_TSTP - if set to a non-null value, this variable causes dpkg to run a
child shell process instead of sending itself a SIGTSTP, when the user selects
to background the dpkg process when it asks about conffiles.
SHELL - used to determine which shell to run in the case when DPKG_NO_TSTP is
set.
CC - used as the C compiler to call to determine the target architecture. The
default is "gcc".
PATH - dpkg checks that it can find at least the following files in the path
when it wants to run package installation scripts, and gives an error if it
cannot find all of them:-
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):-
support-predepends - Returns success or failure according to whether a version
of dpkg which supports predepends properly (1.1.0 or above) is installed,
according to the database.
working-epoch - Return success or failure according to whether a version of
dpkg which supports epochs in version properly (1.4.0.7 or above) is installed,
according to the database.
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.
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:-
Looks at the packages in the database which are selected as
"install", and are installed.
It then looks at the Pre-Depends information for each of these packages from
the available file. When it find a package for which any of the
pre-dependencies are not satisfied, it breaks from the loop through the
packages.
It then looks through the unsatisfied pre-dependencies, and looks for packages
which would satisfy this pre-dependency, stopping on the first it finds. If it
finds none, it bombs out with an error.
It then continues this for every dependency of the initial package.
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).