Packages generally contain all of the files necessary to implement a set of related commands or features. There are two types of Debian packages:
Installation of software by the package system uses
"dependencies" which are carefully designed by
the package maintainers. These dependencies are documented
in the control file associated
with each package. For example, the package containing the
GNU C compiler (gcc) "depends" on the package
binutils which includes the linker and assembler.
If a user attempts to install gcc without having first installed
binutils,
Debian's package system will send an error message that it also needs
binutils, and will install gcc only if the user agrees
to install binutils first. (However, this facility can be
overridden by the insistent user.) More details are given
below on package dependencies.
Debian's packaging tools can be used to:
A Debian "package", or a Debian archive file, contains the
executable files, libraries, and documentation associated with a particular
suite of program or set of related programs. Normally, a Debian archive
file has a filename that ends in .deb.
Debian archive files can be parsed and manipulated by the utility
ar. The precise contents of Debian archive files changed
since Debian 0.93. The new contents are understood by versions of
the primary package tool, dpkg, later than 0.93.76,
and is described in the "deb"(5) man page.
The old format is described in "deb-old"(5).
Using the command ar -t foo_VVV-RRR.deb, one sees that a Debian
archive file contains these members:
gzip'd) tar file
which contains the
Debian control files for
this package. (Confusingly, one of these files, and the only
one which is required, is itself named control.)
gzip'd) tar file
which contains the executables, libraries, documentation, etc.,
associated with this package. In other words, this component is the
filesystem data part of a Debian package.Additional members may be added in the future. Detailed requirements for
adding them are given in the deb manual page.
The Debian package names conform to the following convention: <foo>_<VersionNumber>-<DebianRevisionNumber>_<Arch>.deb
Note that foo is supposed to be the package name. This
naming convention is rather new, and some packages have slightly different
name formats. As a check, one can learn the package name associated with a
particular Debian archive file (.deb file) in one of these ways:
dpkg --info foo_VVV-RRR.deb. This sends
a message to STDOUT which gives, among other things, the
Package Name corresponding to the archive file being unpacked.The VVV component is the version number specified by the
upstream developer. There are no standards in place here, so the version
number may have formats as different as
"960428" and "2.7.2.l.3".
The RRR component is the Debian revision number, and is
specified by the
Debian developer (or an individual user if he chooses to build the package
himself). This number corresponds to the revision level of the Debian
package (which includes the Debian-specific Makefile, called
debian.rules, as well as the Debian control file, usually called
debian.control). Thus, a new revision level usually signifies
changes in the Debian Makefile, the Debian control file, the installation
or removal scripts, or in the configuration files used with the package.
The Arch component identifies the processor for which the
package was built. This is commonly i386, which refers to
chips in the 80x86 family of vintage 80386 or later.
Other possibilities
include m68k for processors in the Motorola 680x0 family, etc.
Specifics regarding the contents of a Debian control file are provided
in the manual page deb-control (5). Briefly,
a sample control file is shown below for the Debian package libc5_5.2.18-9.deb:
PACKAGE: libc5
SECTION: base
SOURCE: libc5
DESCRIPTION: The Linux C library version 5 (run-time libraries).
Includes shared libraries needed to run programs built with libc 5.
MAINTAINER: David Engel <david@ods.com>
VERSION: 5.2.18-9
PRE-DEPENDS: ldso (>=1.7.14-2)
CONFLICTS: elf-libc, pthreads1
REPLACES: elf-libc
PROVIDES: elf-libc, pthreads1
ARCHITECTURE: i386
The first line gives the package name. This is the name by which the package can be manipulated by the package tools, and usually similar to but not necessarily the same as, the first component string in the Debian archive file name.
The second line gives the "section" where this Debian package is stored at the Debian FTP sites. This is the name of a subdirectory (within one of the main directories, see more about the Debian FTP directory structure) where the package is stored.
The Source field identifies the source package from which the
binary package was made. Normally, this is the same as the name of the
package itself. It can be different, however, when one source package
actually provides more than one binary package. For example, three
different binary packages related to the Java Developer's Kit are produced
from the single jdk source package: one for systems with Motif
libraries (jdk-shared), one for systems without Motif
(jdk-static), and one package common to both (jdk-common).
The Description field gives a brief summary of the package's features, and the Maintainer field names the Debian package developer and his email address. The version field gives both the upstream developer's version number and (in the last component) the revision level of the Debian package of this program.
The Pre-Depends field gives a list of packages that have to be available in order to make dpkg even try to install a package. This feature is for expert use only.
The Conflicts field tells the user (and the Debian package maintenance tools) what other packages cannot co-exist with the programs in this package. The Replaces field tells what packages will be replaced when this one is installed. The Provides field tells what packages will be installed by this package; this is a mechanism by which multiple packages can be distributed as a single package, which is in some cases an aid to the package maintenance system.
The final field (Architecture) specifies the chip for which this particular binary was compiled.
Conffiles are listings of configuration files, usually placed in
/etc, that the package management system will not overwrite
when a package is upgraded.
This ensures that local values for the contents of these files
will be preserved, and is a critical feature enabling the in-place upgrade
of packages on a running system.
To determine exactly which files are preserved during an upgrade, users
can inspect the contents of /var/lib/dpkg/info/package_name.conffiles
For example, the netbase.conffiles package contains these entries:
/etc/init.d/netbase
/etc/gateways
/etc/protocols
/etc/services
/etc/hosts.allow
/etc/hosts.deny
/etc/rpc
These files are executable scripts which are automatically run before
or after a package is installed.
Along with a file named control, all of these files are part
of the "control" section of a Debian archive file.
The individual files are:
This script executes the configuration of a package once that package has been unpacked from its Debian archive (".deb") file. Many 'preinst' scripts also stop services for packages which are being upgraded until their installation or upgrade is completed (following the successful execution of the 'postinst' script).
This script typically completes any required
configuration of the package foo once foo has been unpacked
from its Debian archive (".deb") file.
Often, 'postinst' scripts ask the
user for input, and/or warn the user that if he accepts default values,
he should remember to go back and re-configure that package as the
situation warrants. Many 'postinst' scripts then execute any commands
necessary to start or restart a service once a new package has been
installed or upgraded. It is a good idea to check the contents of
the 'postinst' script for any configuration advice, when trying out a
package for the first time.
This script typically stops any daemons which are associated with a package. It is executed before the removal of files associated with the package.
This script typically modifies links or other
files associated with foo. (See notes on
Virtual packages.)
All of the control files can be found in /var/lib/dpkg/info.
The files relevant to package foo begin with the name
"foo" and have file extensions of "preinst",
"postinst", etc., as appropriate. The file foo.list
in that directory
lists all of the files that were installed with the package foo.
Each Debian package is assigned a priority by the distribution maintainers, as an aid to the package management system. The priorities are:
A virtual package is a generic name that applies to any one of a group
of packages, all of which provide similar basic functionality.
For example, both the tin and trn programs
are both news readers, and should therefore satisfy any dependency of
a program that required a news reader on a system in order to work.
They are therefore both said to provide the "virtual package"
called news reader.
Similary, smail and sendmail both provide the
functionality of a mail transport agent. They are therefore said to
provide the virtual package, "mail transport agent".
If either one is installed, then any program depending on the
installation of a mail transport agent will be satisfied by
the existence of this virtual package.
Debian provides a mechanism so that, if more than one package which
provide the same virtual package is installed on a system,
then system administrators can set one as the preferred package.
The relevant command is update-alternatives, and is
described further in the section on
diversions.
The Debian package system has a range of package "dependencies" which are designed to indicate (in a single flag) the level at which Program A can operate independently of the existence of Program B on a given system:
"Pre-Depends" is a special dependency.
In the case of most packages, dpkg will unpack its archive
file (i.e., its .deb file independently of whether or not the
files on which it depends exist on the system. Simplistically,
unpacking means that dpkg will extract the files from the archive
file that were meant to be installed on your filesystem, and put them
in place. If those packages depend on the existence of some
other packages on your system, dpkg will refuse to complete the
installation by executing its "configure" action until the
other packages are installed.
However, for some packages, dpkg will refuse even to unpack
them until certain dependencies are resolved. Such packages are said
to "Pre-depend" on the presence of some other packages.
The Debian project provided this mechanism to support the safe upgrading
of systems from a.out format to ELF format, where
the order in which packages were unpacked was critical.
These "want" flags tell what the user wanted to do with
a package (as indicated either by the user's actions in
the "Select" section of dselect, or by the user's
direct invocations of dpkg). Their meanings are: