The Debian GNU/Linux FAQ
Chapter 6 - Basics of the Debian Package Management System
6.1 What is a Debian package?
Packages generally contain all of the files necessary to implement a set of
related commands or features. There are two types of Debian packages:
Binary packages, which contain executables, configuration files,
man/info pages, copyright information, and other documentation. These packages
are distributed in a Debian-specific archive format (see What is the format of a Debian binary
package?, Section 6.2); they are usually distinguished by having a '.deb'
file extension. Binary packages can be unpacked using the Debian utility
dpkg; details are given in its manual page.
Source packages, which consist of a .dsc file describing
the source package (including the names of the following files), a
.orig.tar.gz file that contains the original unmodified source in
gzip-compressed tar format and usually a .diff.gz file that
contains the Debian-specific changes to the original source. The utility
dpkg-source packs and unpacks Debian source archives; details are
provided in its manual page.
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, the package management system
(dpkg) will send an error message that it also needs binutils, and
stop installing gcc. (However, this facility can be overridden by
the insistent user, see dpkg(8).) See more in What is meant by saying that a package
Depends, Recommends, Suggests, Conflicts,
Replaces or Provides another package?, Section 6.9 below.
Debian's packaging tools can be used to:
manipulate and manage packages or parts of packages,
aid the user in the break-up of packages that must be transmitted through a
limited-size medium such as floppy disks,
aid developers in the construction of package archives, and
aid users in the installation of packages which reside on a remote FTP site.
6.2 What is the format of a Debian binary package?
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.
The internals of this Debian binary packages format are described in the
deb(5) manual page. This internal format is subject to change
(between major releases of Debian GNU/Linux), therefore please always use
dpkg-deb(8) for manipulating .deb files.
6.3 Why are Debian package file names so long?
The Debian binary package file names conform to the following convention:
<foo>_<VersionNumber>-<DebianRevisionNumber>.deb
Note that foo is supposed to be the package name. As a check, one
can learn the package name associated with a particular Debian archive file
(.deb file) in one of these ways:
inspect the "Packages" file in the directory where it was stored at a
Debian FTP archive site. This file contains a stanza describing each package;
the first field in each stanza is the formal package name.
use the command dpkg --info foo_VVV-RRR.deb (where VVV and RRR are
the version and revision of the package in question, respectively). This
displays, 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 "19990513" and "1.3.8pre1".
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, thus, a new revision level usually signifies changes in the Debian
Makefile (debian/rules), the Debian control file
(debian/control), the installation or removal scripts
(debian/p*), or in the configuration files used with the package.
Briefly, a sample control file is shown below for the Debian package hello:
Package: hello
Priority: optional
Section: devel
Installed-Size: 45
Maintainer: Adam Heath <doogie@debian.org>
Architecture: i386
Version: 1.3-16
Depends: libc6 (>= 2.1)
Description: The classic greeting, and a good example
The GNU hello program produces a familiar, friendly greeting. It
allows nonprogrammers to use a classic computer science tool which
would otherwise be unavailable to them.
.
Seriously, though: this is an example of how to do a Debian package.
It is the Debian version of the GNU Project's `hello world' program
(which is itself an example for the GNU Project).
The Package field 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 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 as
explained in Why are Debian package file
names so long?, Section 6.3.
The Architecture field specifies the chip for which this particular binary was
compiled.
The Depends field gives a list of packages that have to be installed in order
to install this package successfully.
The Installed-Size indicates how much disk space the installed package will
consume. This is intended to be used by installation front-ends in order to
show whether there is enough disk space available to install the program .
The Maintainer field gives the e-mail address of the person who is currently
responsible for maintaining this package.
The Description field gives a brief summary of the package's features.
For more information about all possible fields a package can have, please see
the Debian Packaging Manual, section 4., "Control files and their
fields".
6.5 What is a Debian conffile?
Conffiles is a list of configuration files (usually placed in
/etc) that the package management system will not overwrite when
the 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, run:
dpkg --status package
And look under "Conffiles:".
6.6 What is a Debian preinst, postinst, prerm, and postrm script?
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:
preinst
This script executes before that package will be unpacked from its Debian
archive (".deb") file. Many 'preinst' scripts stop services for
packages which are being upgraded until their installation or upgrade is
completed (following the successful execution of the 'postinst' script).
postinst
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.
prerm
This script typically stops any daemons which are associated with a package.
It is executed before the removal of files associated with the package.
postrm
This script typically modifies links or other files associated with
foo, and/or removes files created by the package. (Also see What is a Virtual Package?, Section
6.8.)
Currently all of the control files can be found in directory
/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. (Note that the location of these
files is a dpkg internal; you should not rely on it.)
6.7 What is a Required, Important, Standard, Optional, or Extra package?
Each Debian package is assigned a priority by the distribution
maintainers, as an aid to the package management system. The priorities are:
Required: packages that are necessary for the proper
functioning of the system.
This includes all tools that are necessary to repair system defects. You must
not remove these packages or your system may become totally broken and you may
probably not even be able to use dpkg to put things back. Systems with only
the Required packages are probably unusable, but they do have enough
functionality to allow the sysadmin to boot and install more software.
Important packages should be found on any Unix-like system.
Other packages which the system will not run well or be usable without will be
here. This does NOT include Emacs or X11 or TeX or any other large
applications. These packages only constitute the bare infrastructure.
Standard packages are standard on any Linux system, including
a reasonably small but not too limited character-mode system.
This is what will install by default if users do not select anything else. It
does not include many large applications, but it does include Emacs (this is
more of a piece of infrastructure than an application) and a reasonable subset
of TeX and LaTeX (if this turns out to be possible without X).
Optional packages include all those that you might reasonably
want to install if you did not know what it was, or do not have specialized
requirements.
This includes X11, a full TeX distribution, and lots of applications.
Extra: packages that either conflict with others with higher
priorities, are only likely to be useful if you already know what they are, or
have specialized requirements that make them unsuitable for
"Optional".
6.8 What is a Virtual Package?
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 news readers, and should
therefore satisfy any dependency of a program that required a news reader on a
system, in order to work or to be useful. They are therefore both said to
provide the "virtual package" called news-reader.
Similarly, 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.
6.9 What is meant by saying that a package Depends, Recommends, Suggests, Conflicts, Replaces or Provides another package?
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:
Package A depends on Package B if B absolutely must be installed in
order to run A. In some cases, A depends not only on B, but on a version of B.
In this case, the version dependency is usually a lower limit, in the sense
that A depends on any version of B more recent than some specified version.
Package A recommends Package B, if the package maintainer judges that
most users would not want A without also having the functionality provided by
B.
Package A suggests Package B if B contains files that are related to
(and usually enhance) the functionality of A.
Package A conflicts with Package B when A will not operate if B is
installed on the system. Most often, conflicts are cases where A contains
files which are an improvement over those in B. "Conflicts" are
often combined with "replaces".
Package A replaces Package B when files installed by B are removed and
(in some cases) over-written by files in A.
Package A provides Package B when all of the files and functionality
of B are incorporated into A. This mechanism provides a way for users with
constrained disk space to get only that part of package A which they really
need.
More detailed information on the use of each these terms can be found in the
Packaging manual and the Policy manual.
6.10 What is meant by Pre-Depends?
"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. There are other large upgrade
situations where this method is useful, e.g. the packages with the required
priority and their LibC dependency.
As before, more detailed information about this can be found in the Packaging
manual.
6.11 What is meant by unknown, install, removepurge and hold in the package status?
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:
unknown - the user has never indicated whether he wants the package
install - the user wants the package installed or upgraded
remove - the user wants the package removed, but does not want to remove any
existing configuration files.
purge - the user wants the package to be removed completely, including its
configuration files.
hold - the user wants this package not to be processed, i.e., he wants to keep
the current version with the current status whatever that is.
6.12 How do I put a package on hold?
There are two ways of holding back packages, with dpkg, or with dselect.
With dpkg, you just have to export the list of package selections, with:
dpkg --get-selections \* > selections.txt
Then edit the resulting file selections.txt, change the line
containing the package you wish to hold, e.g. libc6, from this:
libc6 install
to this:
libc6 hold
Save the file, and reload it into dpkg database with:
dpkg --set-selections < selections.txt
With dselect, you just have to enter the [S]elect screen, find the package you
wish to hold in its present state, and press the `=' key (or `H'). The changes
will go live immediately after you exit the [S]elect screen.
6.13 How do I install a source package?
Debian source packages can't actually be "installed", they are just
unpacked in whatever directory you want to build the binary packages they
produce. Source packages are distributed in a directory called
source, and you can either download them manually, or use
apt-get source foo
to fetch them (see apt-get(8) manual page on how to setup APT for
doing that).
6.14 How do I build binary packages from a source package?
You will need all of foo_*.dsc, foo_*.tar.gz and foo_*.diff.gz to compile the
source (note: there is no .diff.gz for a Debian native package).
Once you have them, if you have the dpkg-dev package installed,
the following command:
dpkg-source -x foo_version-revision.dsc
will extract the package into a directory called foo-version.
If you want just to compile the package, you may cd into
foo-version directory and issue the command