<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 7. Basics of the Debian package management system</title><link rel="stylesheet" type="text/css" href="debian.css" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="home" href="index.en.html" title="The Debian GNU/Linux FAQ" /><link rel="up" href="index.en.html" title="The Debian GNU/Linux FAQ" /><link rel="prev" href="ftparchives.en.html" title="Chapter 6. The Debian archives" /><link rel="next" href="pkgtools.en.html" title="Chapter 8. The Debian package management tools" /><meta xmlns="" name="viewport" content="width=device-width, initial-scale=1" /><style xmlns="" type="text/css">
body {
background-repeat: no-repeat;
background-image: none;
}
</style></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 7. Basics of the Debian package management system</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ftparchives.en.html"><img src="images/prev.png" alt="Prev" /></a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="pkgtools.en.html"><img src="images/next.png" alt="Next" /></a></td></tr></table><hr /></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a id="pkg-basics"></a>Chapter 7. Basics of the Debian package management system</h1></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="section"><a href="pkg-basics.en.html#package">7.1. What is a Debian package?</a></span></dt><dt><span class="section"><a href="pkg-basics.en.html#deb-format">7.2. What is the format of a Debian binary package?</a></span></dt><dt><span class="section"><a href="pkg-basics.en.html#pkgname">7.3. Why are Debian package file names so long?</a></span></dt><dt><span class="section"><a href="pkg-basics.en.html#controlfile">7.4. What is a Debian control file?</a></span></dt><dt><span class="section"><a href="pkg-basics.en.html#conffile">7.5. What is a Debian conffile?</a></span></dt><dt><span class="section"><a href="pkg-basics.en.html#maintscripts">7.6. What is a Debian preinst, postinst, prerm, and postrm script?</a></span></dt><dt><span class="section"><a href="pkg-basics.en.html#priority">7.7. What is an <span class="emphasis"><em>Essential</em></span>, <span class="emphasis"><em>Required</em></span>, <span class="emphasis"><em>Important</em></span>, <span class="emphasis"><em>Standard</em></span>, <span class="emphasis"><em>Optional</em></span>, or <span class="emphasis"><em>Extra</em></span> package?</a></span></dt><dt><span class="section"><a href="pkg-basics.en.html#virtual">7.8. What is a Virtual Package?</a></span></dt><dt><span class="section"><a href="pkg-basics.en.html#depends">7.9. What is meant by saying that a package <span class="emphasis"><em>Depends</em></span>, <span class="emphasis"><em>Recommends</em></span>, <span class="emphasis"><em>Suggests</em></span>, <span class="emphasis"><em>Conflicts</em></span>, <span class="emphasis"><em>Replaces</em></span>, <span class="emphasis"><em>Breaks</em></span> or <span class="emphasis"><em>Provides</em></span> another package?</a></span></dt><dt><span class="section"><a href="pkg-basics.en.html#pre-depends">7.10. What is meant by Pre-Depends?</a></span></dt><dt><span class="section"><a href="pkg-basics.en.html#pkgstatus">7.11. What is meant by <span class="emphasis"><em>unknown</em></span>, <span class="emphasis"><em>install</em></span>, <span class="emphasis"><em>remove</em></span>, <span class="emphasis"><em>purge</em></span> and <span class="emphasis"><em>hold</em></span> in the package status?</a></span></dt><dt><span class="section"><a href="pkg-basics.en.html#puttingonhold">7.12. How do I put a package on hold?</a></span></dt><dt><span class="section"><a href="pkg-basics.en.html#sourcepkgs">7.13. How do I install a source package?</a></span></dt><dt><span class="section"><a href="pkg-basics.en.html#sourcebuild">7.14. How do I build binary packages from a source package?</a></span></dt><dt><span class="section"><a href="pkg-basics.en.html#creatingdebs">7.15. How do I create Debian packages myself?</a></span></dt></dl></div><p>
This chapter touches on some lower level internals of Debian package
management. If you're interested mainly in <span class="emphasis"><em>usage</em></span> of the
relevant tools, skip to chapters <a class="xref" href="pkgtools.en.html" title="Chapter 8. The Debian package management tools">Chapter 8, <em>The Debian package management tools</em></a> and/or <a class="xref" href="uptodate.en.html" title="Chapter 9. Keeping your Debian system up-to-date">Chapter 9, <em>Keeping your Debian system up-to-date</em></a>.
</p><div class="section"><div class="titlepage"><div><div><h2 class="title"><a id="package"></a>7.1. What is a Debian package?</h2></div></div></div><p>
Packages generally contain all of the files necessary to implement a set of
related commands or features. There are two types of Debian packages:
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
<span class="emphasis"><em>Binary packages</em></span>, which contain executables, configuration
files, man/info pages, copyright information, and other documentation. These
packages are distributed in a Debian-specific archive format (see <a class="xref" href="pkg-basics.en.html#deb-format" title="7.2. What is the format of a Debian binary package?">Section 7.2, “What is the format of a Debian binary package?”</a>); they are usually characterized by having a '.deb' file
extension. Binary packages can be unpacked using the Debian utility
<code class="literal">dpkg</code> (possibly via a frontend like
<span class="command"><strong>aptitude</strong></span>); details are given in its manual page.
</p></li><li class="listitem"><p>
<span class="emphasis"><em>Source packages</em></span>, which consist of a
<code class="literal">.dsc</code> file describing the source package (including the names
of the following files), a <code class="literal">.orig.tar.gz</code> file that contains
the original unmodified source in gzip-compressed tar format and usually a
<code class="literal">.diff.gz</code> file that contains the Debian-specific changes to
the original source. The utility <code class="literal">dpkg-source</code> packs and
unpacks Debian source archives; details are provided in its manual page. (The
program <span class="command"><strong>apt-get</strong></span> can be used as a frontend for
<code class="literal">dpkg-source</code>.)
</p></li></ul></div><p>
Installation of software by the package system uses "dependencies" which are
carefully designed by the package maintainers. These dependencies are
documented in the <code class="literal">control</code> file associated with each package.
For example, the package containing the GNU C compiler (<code class="systemitem">gcc</code><a id="idm990" class="indexterm"></a>) "depends" on the package <code class="systemitem">binutils</code><a id="idm994" class="indexterm"></a> which includes the linker and assembler.
If a user attempts to install <code class="systemitem">gcc</code><a id="idm998" class="indexterm"></a>
without having first installed <code class="systemitem">binutils</code><a id="idm1002" class="indexterm"></a>, the package management system (dpkg) will
send an error message that it also needs <code class="systemitem">binutils</code><a id="idm1006" class="indexterm"></a>, and stop installing <code class="systemitem">gcc</code><a id="idm1010" class="indexterm"></a>. (However, this facility can be overridden by
the insistent user, see
<span class="citerefentry"><span class="refentrytitle">dpkg</span>(8)</span>.)
See more in <a class="xref" href="pkg-basics.en.html#depends" title="7.9. What is meant by saying that a package Depends, Recommends, Suggests, Conflicts, Replaces, Breaks or Provides another package?">Section 7.9, “What is meant by saying that a package <span class="emphasis"><em>Depends</em></span>, <span class="emphasis"><em>Recommends</em></span>, <span class="emphasis"><em>Suggests</em></span>, <span class="emphasis"><em>Conflicts</em></span>, <span class="emphasis"><em>Replaces</em></span>, <span class="emphasis"><em>Breaks</em></span> or <span class="emphasis"><em>Provides</em></span> another package?”</a> below.
</p><p>
Debian's packaging tools can be used to:
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
manipulate and manage packages or parts of packages,
</p></li><li class="listitem"><p>
administer local overrides of files in a package,
</p></li><li class="listitem"><p>
aid developers in the construction of package archives, and
</p></li><li class="listitem"><p>
aid users in the installation of packages which reside on a remote archive site.
</p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a id="deb-format"></a>7.2. What is the format of a Debian binary package?</h2></div></div></div><p>
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 <code class="literal">.deb</code>.
</p><p>
The internals of this Debian binary packages format are described in the
<span class="citerefentry"><span class="refentrytitle">deb</span>(5)</span>
manual page. This internal format is subject to change (between major releases
of Debian GNU/Linux), therefore please always use
<span class="citerefentry"><span class="refentrytitle">dpkg-deb</span>(1)</span>
if you need to do lowlevel manipulations on <code class="literal">.deb</code> files.
</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a id="pkgname"></a>7.3. Why are Debian package file names so long?</h2></div></div></div><p>
The Debian binary package file names conform to the following convention:
<foo>_<VersionNumber>-<DebianRevisionNumber>_<DebianArchitecture>.deb
</p><p>
Note that <code class="literal">foo</code> is supposed to be the package name. Checking
the package name associated with a particular Debian archive file (.deb file)
can be done in one of these ways:
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
inspect the "Packages" file in the directory where it was stored at a Debian
archive site. This file contains a stanza describing each package; the
first field in each stanza is the formal package name.
</p></li><li class="listitem"><p>
use the command <code class="literal">dpkg --info foo_VVV-RRR_AAA.deb</code> (where VVV,
RRR and AAA are the version, revision and architecture of the package in
question, respectively). This displays, among other things, the package name
corresponding to the archive file being unpacked.
</p></li></ul></div><p>
The <code class="literal">VVV</code> 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".
</p><p>
The <code class="literal">RRR</code> component is the Debian revision number, and is
specified by the Debian developer (or a user who chooses to rebuild
the package locally). This number corresponds to the revision level of the
Debian package, thus, a new revision level usually signifies changes in the
Debian Makefile (<code class="literal">debian/rules</code>), the Debian control file
(<code class="literal">debian/control</code>), the installation or removal scripts
(<code class="literal">debian/p*</code>), or in the configuration files used with the
package.
</p><p>
The <code class="literal">AAA</code> component identifies the processor for which the
package was built. This is commonly <code class="literal">amd64</code>, which refers to
AMD64, Intel 64 or VIA Nano chips. For other possibilities review Debian's archive
directory structure at <a class="xref" href="ftparchives.en.html#dirtree" title="6.7. What are all those directories at the Debian archives?">Section 6.7, “What are all those directories at the Debian archives?”</a>. For details, see the
description of "Debian architecture" in the manual page
<span class="citerefentry"><span class="refentrytitle">dpkg-architecture</span>(1)</span>.
</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a id="controlfile"></a>7.4. What is a Debian control file?</h2></div></div></div><p>
Specifics regarding the contents of a Debian control file are provided in the
Debian Policy Manual, section 5, see <a class="xref" href="support.en.html#debiandocs" title="12.1. What other documentation exists on and for a Debian system?">Section 12.1, “What other documentation exists on and for a Debian system?”</a>.
</p><p>
Briefly, a sample control file is shown below for the Debian package hello:
</p><pre class="screen">
Package: hello
Version: 2.9-2+deb8u1
Architecture: amd64
Maintainer: Santiago Vila <sanvila@debian.org>
Installed-Size: 145
Depends: libc6 (>= 2.14)
Conflicts: hello-traditional
Breaks: hello-debhelper (<< 2.9)
Replaces: hello-debhelper (<< 2.9), hello-traditional
Section: devel
Priority: optional
Homepage: https://www.gnu.org/software/hello/
Description: example package based on GNU hello
The GNU hello program produces a familiar, friendly greeting. It
allows non-programmers 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).
</pre><p>
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.
</p><p>
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 <a class="xref" href="pkg-basics.en.html#pkgname" title="7.3. Why are Debian package file names so long?">Section 7.3, “Why are Debian package file names so long?”</a>.
</p><p>
The Architecture field specifies the chip for which this particular binary was
compiled.
</p><p>
The Depends field gives a list of packages that have to be installed in order
to install this package successfully.
</p><p>
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.
</p><p>
The Section line gives the "section" where this Debian package is stored at the
Debian archive sites.
</p><p>
The Priority indicates how important is this package for installation, so that
semi-intelligent software like apt or aptitude can sort the package into a
category of e.g. packages optionally installed. See <a class="xref" href="pkg-basics.en.html#priority" title="7.7. What is an Essential, Required, Important, Standard, Optional, or Extra package?">Section 7.7, “What is an <span class="emphasis"><em>Essential</em></span>, <span class="emphasis"><em>Required</em></span>, <span class="emphasis"><em>Important</em></span>, <span class="emphasis"><em>Standard</em></span>, <span class="emphasis"><em>Optional</em></span>, or <span class="emphasis"><em>Extra</em></span> package?”</a>.
</p><p>
The Maintainer field gives the e-mail address of the person who is currently
responsible for maintaining this package.
</p><p>
The Description field gives a brief summary of the package's features.
</p><p>
For more information about all possible fields a package can have, please see
the Debian Policy Manual, section 5, "Control files and their fields", see
<a class="xref" href="support.en.html#debiandocs" title="12.1. What other documentation exists on and for a Debian system?">Section 12.1, “What other documentation exists on and for a Debian system?”</a>.
</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a id="conffile"></a>7.5. What is a Debian conffile?</h2></div></div></div><p>
Conffiles is a list of configuration files (usually placed in
<code class="literal">/etc</code>) 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.
</p><p>
To determine exactly which files are preserved during an upgrade, run:
</p><pre class="screen">
dpkg --status package
</pre><p>
And look under "Conffiles:".
</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a id="maintscripts"></a>7.6. What is a Debian preinst, postinst, prerm, and postrm script?</h2></div></div></div><p>
These files are executable scripts which are automatically run before or after
a package is installed or removed. Along with a file named
<code class="literal">control</code>, all of these files are part of the "control"
section of a Debian archive file.
</p><p>
The individual files are:
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">preinst</span></dt><dd><p>
This script is executed before the package it belongs to is 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).
</p></dd><dt><span class="term">postinst</span></dt><dd><p>
This script typically completes any required configuration of the package
<code class="literal">foo</code> once <code class="literal">foo</code> has been unpacked from its
Debian archive (".deb") file. Often, 'postinst' scripts ask users for input,
and/or warn them that if they accept default values, they should remember to go
back and re-configure that package as needed. Many 'postinst' scripts then
execute any commands necessary to start or restart a service once a new package
has been installed or upgraded.
</p></dd><dt><span class="term">prerm</span></dt><dd><p>
This script typically stops any daemons which are associated with a package.
It is executed before the removal of files associated with the package.
</p></dd><dt><span class="term">postrm</span></dt><dd><p>
This script typically modifies links or other files associated with
<code class="literal">foo</code>, and/or removes files created by the package. (Also see
<a class="xref" href="pkg-basics.en.html#virtual" title="7.8. What is a Virtual Package?">Section 7.8, “What is a Virtual Package?”</a>.)
</p></dd></dl></div><p>
Currently all of the control files can be found in the directory
<code class="literal">/var/lib/dpkg/info</code>. The files relevant to package
<code class="literal">foo</code> begin with the name "foo" and have file extensions of
"preinst", "postinst", etc., as appropriate. The file
<code class="literal">foo.list</code> in that directory lists all of the files that were
installed with the package <code class="literal">foo</code>. (Note that the location of
these files is a dpkg internal; you should not rely on it.)
</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a id="priority"></a>7.7. What is an <span class="emphasis"><em>Essential</em></span>, <span class="emphasis"><em>Required</em></span>, <span class="emphasis"><em>Important</em></span>, <span class="emphasis"><em>Standard</em></span>, <span class="emphasis"><em>Optional</em></span>, or <span class="emphasis"><em>Extra</em></span> package?</h2></div></div></div><p>
Each Debian package is assigned a <span class="emphasis"><em>priority</em></span> by the
distribution maintainers, as an aid to the package management system. The
priorities are:
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
<span class="strong"><strong>Required</strong></span>: packages that are necessary for
the proper functioning of the system.
</p><p>
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.
</p></li><li class="listitem"><p>
<span class="strong"><strong>Important</strong></span> packages should be found on any
Unix-like system.
</p><p>
Other packages which the system will not run well or be usable without will be
here. This does <span class="emphasis"><em>NOT</em></span> include Emacs or X or TeX or any
other large application. These packages only constitute the bare
infrastructure.
</p></li><li class="listitem"><p>
<span class="strong"><strong>Standard</strong></span> packages are standard on any Linux
system, including a reasonably small but not too limited character-mode system.
Tools are included to be able to send e-mail (with mutt) and download files
from archive servers.
</p><p>
This is what will be installed by default if users do not select anything else.
It does not include many large applications, but it does include the Python
interpreter and some server software like OpenSSH (for remote administration)
and Exim (for mail delivery, although it can be configured for local delivery
only). It also includes some common generic documentation that most users will
find helpful.
</p></li><li class="listitem"><p>
<span class="strong"><strong>Optional</strong></span> packages include all those that you
might reasonably want to install if you do not know what they are, or that do
not have specialized requirements.
</p><p>
This includes X, a full TeX distribution, and lots of applications.
</p></li><li class="listitem"><p>
<span class="strong"><strong>Extra</strong></span>: 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".
</p></li></ul></div><p>
If you do a default Debian installation all the packages of priority <span class="strong"><strong>Standard</strong></span> or higher will be installed in your system.
If you select pre-defined tasks you will get lower priority packages too.
</p><p>
Additionally, some packages are marked as <span class="strong"><strong>Essential</strong></span> since they are absolutely necessary for the
proper functioning of the system. The package management tools will refuse to
remove these.
</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a id="virtual"></a>7.8. What is a Virtual Package?</h2></div></div></div><p>
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 <code class="literal">konqueror</code> and <code class="literal">firefox-esr</code> programs
are web browsers, and should therefore satisfy any dependency of a program that
requires a web browser on a system, in order to work or to be useful. They are
therefore both said to provide the "virtual package" called
<code class="literal">www-browser</code>.
</p><p>
Similarly, <code class="literal">exim4</code> and <code class="literal">sendmail</code> 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
<code class="literal">mail-transport-agent</code> will be satisfied by the presence of
this virtual package.
</p><p>
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
<code class="literal">update-alternatives</code>, and is described further in <a class="xref" href="customizing.en.html#diverse" title="11.11. Some users like mawk, others like gawk; some like vim, others like elvis; some like trn, others like tin; how does Debian support diversity?">Section 11.11, “Some users like mawk, others like gawk; some like vim, others like elvis; some like trn, others like tin; how does Debian support diversity?”</a>.
</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a id="depends"></a>7.9. What is meant by saying that a package <span class="emphasis"><em>Depends</em></span>, <span class="emphasis"><em>Recommends</em></span>, <span class="emphasis"><em>Suggests</em></span>, <span class="emphasis"><em>Conflicts</em></span>, <span class="emphasis"><em>Replaces</em></span>, <span class="emphasis"><em>Breaks</em></span> or <span class="emphasis"><em>Provides</em></span> another package?</h2></div></div></div><p>
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:
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
Package A <span class="emphasis"><em>depends</em></span> 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.
</p></li><li class="listitem"><p>
Package A <span class="emphasis"><em>recommends</em></span> Package B, if the package maintainer
judges that most users would not want A without also having the functionality
provided by B.
</p></li><li class="listitem"><p>
Package A <span class="emphasis"><em>suggests</em></span> Package B if B contains files that are
related to (and usually enhance) the functionality of A.
</p></li><li class="listitem"><p>
Package A <span class="emphasis"><em>conflicts</em></span> 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".
</p></li><li class="listitem"><p>
Package A <span class="emphasis"><em>replaces</em></span> Package B when files installed by B are
removed and (in some cases) over-written by files in A.
</p></li><li class="listitem"><p>
Package A <span class="emphasis"><em>breaks</em></span> Package B when both packages cannot be
simultaneously configured in a system. The package management system will
refuse to install one if the other one is already installed and configured in
the system.
</p></li><li class="listitem"><p>
Package A <span class="emphasis"><em>provides</em></span> 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.
</p></li></ul></div><p>
More detailed information on the use of each of these terms can be found in the
Debian Policy manual, section 7.2, "Binary Dependencies", see <a class="xref" href="support.en.html#debiandocs" title="12.1. What other documentation exists on and for a Debian system?">Section 12.1, “What other documentation exists on and for a Debian system?”</a>.
</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a id="pre-depends"></a>7.10. What is meant by Pre-Depends?</h2></div></div></div><p>
"Pre-Depends" is a special dependency. In the case of most packages,
<code class="literal">dpkg</code> will unpack the archive file of a package (i.e., its
<code class="literal">.deb</code> file) independently of whether or not the files on
which it depends exist on the system. Simplistically, unpacking means that
<code class="literal">dpkg</code> will extract the files from the archive file that were
meant to be installed on your file system, and put them in place. If those
packages <span class="emphasis"><em>depend</em></span> on the existence of some other packages on
your system, <code class="literal">dpkg</code> will refuse to complete the installation
(by executing its "configure" action) until the other packages are installed.
</p><p>
However, for some packages, <code class="literal">dpkg</code> 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
<code class="literal">a.out</code> format to <code class="literal">ELF</code> format, where the
<span class="emphasis"><em>order</em></span> 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.
</p><p>
As before, more detailed information about this can be found in the Policy
manual.
</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a id="pkgstatus"></a>7.11. What is meant by <span class="emphasis"><em>unknown</em></span>, <span class="emphasis"><em>install</em></span>, <span class="emphasis"><em>remove</em></span>, <span class="emphasis"><em>purge</em></span> and <span class="emphasis"><em>hold</em></span> in the package status?</h2></div></div></div><p>
These "want" flags tell what the user wanted to do with a package (as indicated
by the user's direct invocations of
<code class="literal">dpkg</code>/<code class="literal">apt</code>/ <code class="literal">aptitude</code>).
</p><p>
Their meanings are:
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
unknown - the user has never indicated whether the package is wanted.
</p></li><li class="listitem"><p>
install - the user wants the package installed or upgraded.
</p></li><li class="listitem"><p>
remove - the user wants the package removed, but does not want to remove any
existing configuration file.
</p></li><li class="listitem"><p>
purge - the user wants the package to be removed completely, including its
configuration files.
</p></li><li class="listitem"><p>
hold - the user wants this package not to be processed, i.e. wants to keep the
current version with the current status whatever that is.
</p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a id="puttingonhold"></a>7.12. How do I put a package on hold?</h2></div></div></div><p>
There are three ways of holding back packages, with dpkg, apt or aptitude.
</p><p>
With dpkg, you have to export the list of package selections, with:
</p><pre class="screen">
dpkg --get-selections \* > selections.txt
</pre><p>
Then edit the resulting file <code class="filename">selections.txt</code>, change the
line containing the package you wish to hold, e.g. <code class="systemitem">libc6</code><a id="idm1248" class="indexterm"></a>, from this:
</p><pre class="screen">
libc6 install
</pre><p>
to this:
</p><pre class="screen">
libc6 hold
</pre><p>
Save the file, and reload it into dpkg database with:
</p><pre class="screen">
dpkg --set-selections < selections.txt
</pre><p>
With apt, you can set a package to hold using
</p><pre class="screen">
apt-mark hold package_name
</pre><p>
and remove the hold with
</p><pre class="screen">
apt-mark unhold package_name
</pre><p>
With aptitude, you can hold a package using
</p><pre class="screen">
aptitude hold package_name
</pre><p>
and remove the hold with
</p><pre class="screen">
aptitude unhold package_name
</pre></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a id="sourcepkgs"></a>7.13. How do I install a source package?</h2></div></div></div><p>
Debian source packages can't actually be "installed", they are just unpacked in
whatever directory you want to build the binary packages they produce.
</p><p>
Source packages are distributed on most of the same mirrors where you can
obtain the binary packages. If you set up your APT's
<span class="citerefentry"><span class="refentrytitle">sources.list</span>(5)</span>
to include the appropriate "deb-src" lines, you'll be able to easily download
any source package by running
</p><pre class="screen">
apt-get source foo
</pre><p>
To help you in actually building the source package, Debian source packages
provide the so-called build-dependencies mechanism. This means that the source
package maintainer keeps a list of other packages that are required to build
their package. To see how this is useful, run
</p><pre class="screen">
apt-get build-dep foo
</pre><p>
before building the source.
</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a id="sourcebuild"></a>7.14. How do I build binary packages from a source package?</h2></div></div></div><p>
The preferred way to do this is by using various wrapper tools. We'll show how
it's done using the <code class="literal">devscripts</code> tools. Install this package
if you haven't done so already.
</p><p>
Now, first get the source package:
</p><pre class="screen">
apt-get source foo
</pre><p>
and change to the source tree:
</p><pre class="screen">
cd foo-*
</pre><p>
Then install needed build-dependencies (if any):
</p><pre class="screen">
sudo apt-get build-dep foo
</pre><p>
Then create a dedicated version of your own build (so that you won't get
confused later when Debian itself releases a new version):
</p><pre class="screen">
dch -l local 'Blah blah blah'
</pre><p>
And finally build your package:
</p><pre class="screen">
debuild -us -uc
</pre><p>
If everything worked out fine, you should now be able to install your package
by running
</p><pre class="screen">
sudo dpkg -i ../*.deb
</pre><p>
If you prefer to do things manually, and don't want to use
<code class="literal">devscripts</code>, follow this procedure:
</p><p>
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 some packages that are native to
Debian).
</p><p>
Once you have them (<a class="xref" href="pkg-basics.en.html#sourcepkgs" title="7.13. How do I install a source package?">Section 7.13, “How do I install a source package?”</a>) and if you have the
<code class="systemitem">dpkg-dev</code><a id="idm1297" class="indexterm"></a> package installed, the
following command:
</p><pre class="screen">
dpkg-source -x foo_version-revision.dsc
</pre><p>
will extract the package into a directory called
<code class="literal">foo-version</code>.
</p><p>
If you just want to compile the package, you may cd into the
<code class="literal">foo-version</code> directory and issue the command
</p><pre class="screen">
dpkg-buildpackage -rfakeroot -b
</pre><p>
to build the package (note that this also requires the <code class="systemitem">fakeroot</code><a id="idm1308" class="indexterm"></a> package), and then
</p><pre class="screen">
dpkg -i ../foo_version-revision_arch.deb
</pre><p>
to install the newly-built package(s).
</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a id="creatingdebs"></a>7.15. How do I create Debian packages myself?</h2></div></div></div><p>
For a more detailed description on this, read the New Maintainers' Guide,
available in the <code class="systemitem">maint-guide</code><a id="idm1317" class="indexterm"></a> package or
at <a class="ulink" href="https://www.debian.org/doc/devel-manuals#maint-guide" target="_top">https://www.debian.org/doc/devel-manuals#maint-guide</a>,
or the Guide for Debian Maintainers, available in the <code class="systemitem">debmake-doc</code><a id="idm1322" class="indexterm"></a> package or at <a class="ulink" href="https://www.debian.org/doc/devel-manuals#debmake-doc" target="_top">https://www.debian.org/doc/devel-manuals#debmake-doc</a>.
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ftparchives.en.html"><img src="images/prev.png" alt="Prev" /></a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="pkgtools.en.html"><img src="images/next.png" alt="Next" /></a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 6. The Debian archives </td><td width="20%" align="center"><a accesskey="h" href="index.en.html"><img src="images/home.png" alt="Home" /></a></td><td width="40%" align="right" valign="top"> Chapter 8. The Debian package management tools</td></tr></table></div></body></html> |