861 lines
25 KiB
HTML
861 lines
25 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
|
|
|
|
<html>
|
|
|
|
<head>
|
|
|
|
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
|
|
|
|
<title>The Debian GNU/Linux FAQ - Basics of the Debian package management system</title>
|
|
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<p><a name="ch-pkg_basics"></a></p>
|
|
<hr>
|
|
|
|
<p>
|
|
[ <a href="ch-ftparchives.en.html">previous</a> ]
|
|
[ <a href="index.en.html#contents">Contents</a> ]
|
|
[ <a href="ch-basic_defs.en.html">1</a> ]
|
|
[ <a href="ch-getting.en.html">2</a> ]
|
|
[ <a href="ch-compat.en.html">3</a> ]
|
|
[ <a href="ch-software.en.html">4</a> ]
|
|
[ <a href="ch-ftparchives.en.html">5</a> ]
|
|
[ 6 ]
|
|
[ <a href="ch-pkgtools.en.html">7</a> ]
|
|
[ <a href="ch-uptodate.en.html">8</a> ]
|
|
[ <a href="ch-kernel.en.html">9</a> ]
|
|
[ <a href="ch-customizing.en.html">10</a> ]
|
|
[ <a href="ch-support.en.html">11</a> ]
|
|
[ <a href="ch-contributing.en.html">12</a> ]
|
|
[ <a href="ch-redistrib.en.html">13</a> ]
|
|
[ <a href="ch-nexttime.en.html">14</a> ]
|
|
[ <a href="ch-faqinfo.en.html">15</a> ]
|
|
[ <a href="ch-pkgtools.en.html">next</a> ]
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h1>
|
|
The Debian GNU/Linux FAQ
|
|
<br>Chapter 6 - Basics of the Debian package management system
|
|
</h1>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-package"></a>6.1 What is a Debian package?</h2>
|
|
|
|
<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>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<em>Binary packages</em>, 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
|
|
href="#s-deb-format">What is the format of a Debian binary package?, Section
|
|
6.2</a>); they are usually distinguished by having a '.deb' file extension.
|
|
Binary packages can be unpacked using the Debian utility <samp>dpkg</samp>;
|
|
details are given in its manual page.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<em>Source packages</em>, which consist of a <samp>.dsc</samp> file describing
|
|
the source package (including the names of the following files), a
|
|
<samp>.orig.tar.gz</samp> file that contains the original unmodified source in
|
|
gzip-compressed tar format and usually a <samp>.diff.gz</samp> file that
|
|
contains the Debian-specific changes to the original source. The utility
|
|
<samp>dpkg-source</samp> packs and unpacks Debian source archives; details are
|
|
provided in its manual page.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
Installation of software by the package system uses "dependencies"
|
|
which are carefully designed by the package maintainers. These dependencies
|
|
are documented in the <samp>control</samp> file associated with each package.
|
|
For example, the package containing the GNU C compiler (<code>gcc</code>)
|
|
"depends" on the package <code>binutils</code> which includes the
|
|
linker and assembler. If a user attempts to install <code>gcc</code> without
|
|
having first installed <code>binutils</code>, the package management system
|
|
(dpkg) will send an error message that it also needs <code>binutils</code>, and
|
|
stop installing <code>gcc</code>. (However, this facility can be overridden by
|
|
the insistent user, see <code>dpkg(8)</code>.) See more in <a
|
|
href="#s-depends">What is meant by saying that a package <em>Depends</em>,
|
|
<em>Recommends</em>, <em>Suggests</em>, <em>Conflicts</em>, <em>Replaces</em>
|
|
or <em>Provides</em> another package?, Section 6.9</a> below.
|
|
</p>
|
|
|
|
<p>
|
|
Debian's packaging tools can be used to:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
manipulate and manage packages or parts of packages,
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
aid the user in the break-up of packages that must be transmitted through a
|
|
limited-size medium such as floppy disks,
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
aid developers in the construction of package archives, and
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
aid users in the installation of packages which reside on a remote FTP site.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-deb-format"></a>6.2 What is the format of a Debian binary package?</h2>
|
|
|
|
<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 <samp>.deb</samp>.
|
|
</p>
|
|
|
|
<p>
|
|
The internals of this Debian binary packages format are described in the
|
|
<code>deb(5)</code> manual page. This internal format is subject to change
|
|
(between major releases of Debian GNU/Linux), therefore please always use
|
|
<code>dpkg-deb(1)</code> for manipulating <samp>.deb</samp> files.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-pkgname"></a>6.3 Why are Debian package file names so long?</h2>
|
|
|
|
<p>
|
|
The Debian binary package file names conform to the following convention:
|
|
<foo>_<VersionNumber>-<DebianRevisionNumber>.deb
|
|
</p>
|
|
|
|
<p>
|
|
Note that <samp>foo</samp> 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:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
use the command <samp>dpkg --info foo_VVV-RRR.deb</samp> (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.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
The <samp>VVV</samp> 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 <samp>RRR</samp> 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 (<samp>debian/rules</samp>), the Debian control file
|
|
(<samp>debian/control</samp>), the installation or removal scripts
|
|
(<samp>debian/p*</samp>), or in the configuration files used with the package.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-controlfile"></a>6.4 What is a Debian control file?</h2>
|
|
|
|
<p>
|
|
Specifics regarding the contents of a Debian control file are provided in the
|
|
Debian Policy Manual, section 5, see <a
|
|
href="ch-support.en.html#s-debiandocs">What other documentation exists on and
|
|
for a Debian system?, Section 11.1</a>.
|
|
</p>
|
|
|
|
<p>
|
|
Briefly, a sample control file is shown below for the Debian package hello:
|
|
</p>
|
|
|
|
<pre>
|
|
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).
|
|
</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 href="#s-pkgname">Why are Debian package file names so long?,
|
|
Section 6.3</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 FTP sites. This is the name of a subdirectory (within one
|
|
of the main directories, see <a href="ch-ftparchives.en.html#s-dirtree">What
|
|
are all those directories at the Debian FTP archives?, Section 5.1</a>) where
|
|
the package is stored.
|
|
</p>
|
|
|
|
<p>
|
|
The Priority indicates how important is this package for installation, so that
|
|
semi-intelligent software like dselect or console-apt can sort the package into
|
|
a category of e.g. packages optionally installed. See <a
|
|
href="#s-priority">What is an <em>Essential</em> <em>Required</em>,
|
|
<em>Important</em>, <em>Standard</em>, <em>Optional</em>, or <em>Extra</em>
|
|
package?, Section 6.7</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".
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-conffile"></a>6.5 What is a Debian conffile?</h2>
|
|
|
|
<p>
|
|
Conffiles is a list of configuration files (usually placed in
|
|
<samp>/etc</samp>) 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>
|
|
dpkg --status package
|
|
</pre>
|
|
|
|
<p>
|
|
And look under "Conffiles:".
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-maintscripts"></a>6.6 What is a Debian preinst, postinst, prerm, and postrm script?</h2>
|
|
|
|
<p>
|
|
These files are executable scripts which are automatically run before or after
|
|
a package is installed. Along with a file named <samp>control</samp>, all of
|
|
these files are part of the "control" section of a Debian archive
|
|
file.
|
|
</p>
|
|
|
|
<p>
|
|
The individual files are:
|
|
</p>
|
|
<dl>
|
|
<dt>preinst</dt>
|
|
<dd>
|
|
<p>
|
|
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).
|
|
</p>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt>postinst</dt>
|
|
<dd>
|
|
<p>
|
|
This script typically completes any required configuration of the package
|
|
<samp>foo</samp> once <samp>foo</samp> 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.
|
|
</p>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt>prerm</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>
|
|
</dl>
|
|
<dl>
|
|
<dt>postrm</dt>
|
|
<dd>
|
|
<p>
|
|
This script typically modifies links or other files associated with
|
|
<samp>foo</samp>, and/or removes files created by the package. (Also see <a
|
|
href="#s-virtual">What is a Virtual Package?, Section 6.8</a>.)
|
|
</p>
|
|
</dd>
|
|
</dl>
|
|
|
|
<p>
|
|
Currently all of the control files can be found in directory
|
|
<samp>/var/lib/dpkg/info</samp>. The files relevant to package
|
|
<samp>foo</samp> begin with the name "foo" and have file extensions
|
|
of "preinst", "postinst", etc., as appropriate. The file
|
|
<samp>foo.list</samp> in that directory lists all of the files that were
|
|
installed with the package <samp>foo</samp>. (Note that the location of these
|
|
files is a dpkg internal; you should not rely on it.)
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-priority"></a>6.7 What is an <em>Essential</em> <em>Required</em>, <em>Important</em>, <em>Standard</em>, <em>Optional</em>, or <em>Extra</em> package?</h2>
|
|
|
|
<p>
|
|
Each Debian package is assigned a <em>priority</em> by the distribution
|
|
maintainers, as an aid to the package management system. The priorities are:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<strong>Required</strong>: 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>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<strong>Important</strong> 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 <em>NOT</em> include Emacs or X11 or TeX or any other large
|
|
applications. These packages only constitute the bare infrastructure.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<strong>Standard</strong> packages are standard on any Linux system, including
|
|
a reasonably small but not too limited character-mode system.
|
|
</p>
|
|
|
|
<p>
|
|
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 some development
|
|
software like the GNU C and C++ compilers (<samp>gcc</samp>, <samp>g++</samp>),
|
|
GNU make, as well as the Python interpreter and some server software like
|
|
OpenSSH, the BSD printer daemon (<samp>lpr</samp>) and the RPC portmapper
|
|
(<samp>portmap</samp>).
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<strong>Optional</strong> 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.
|
|
</p>
|
|
|
|
<p>
|
|
This includes X11, a full TeX distribution, and lots of applications.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
<strong>Extra</strong>: 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>
|
|
|
|
<p>
|
|
If you do a default Debian installation all the packages of priority
|
|
<strong>Standard</strong> 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 <strong>Essential</strong> since they
|
|
are absolutely necessary for the proper functioning of the system. The package
|
|
management tools will refuse to remove these.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-virtual"></a>6.8 What is a Virtual Package?</h2>
|
|
|
|
<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 <samp>tin</samp> and <samp>trn</samp> 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 <samp>news-reader</samp>.
|
|
</p>
|
|
|
|
<p>
|
|
Similarly, <samp>smail</samp> and <samp>sendmail</samp> 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
|
|
<samp>mail-transport-agent</samp> will be satisfied by the existence 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
|
|
<samp>update-alternatives</samp>, and is described further in <a
|
|
href="ch-customizing.en.html#s-diverse">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 10.10</a>.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-depends"></a>6.9 What is meant by saying that a package <em>Depends</em>, <em>Recommends</em>, <em>Suggests</em>, <em>Conflicts</em>, <em>Replaces</em> or <em>Provides</em> another package?</h2>
|
|
|
|
<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>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
Package A <em>depends</em> 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>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
Package A <em>recommends</em> Package B, if the package maintainer judges that
|
|
most users would not want A without also having the functionality provided by
|
|
B.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
Package A <em>suggests</em> Package B if B contains files that are related to
|
|
(and usually enhance) the functionality of A.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
Package A <em>conflicts</em> 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>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
Package A <em>replaces</em> Package B when files installed by B are removed and
|
|
(in some cases) over-written by files in A.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
Package A <em>provides</em> 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>
|
|
|
|
<p>
|
|
More detailed information on the use of each these terms can be found in the
|
|
Policy manual.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-pre-depends"></a>6.10 What is meant by Pre-Depends?</h2>
|
|
|
|
<p>
|
|
"Pre-Depends" is a special dependency. In the case of most packages,
|
|
<samp>dpkg</samp> will unpack its archive file (i.e., its <samp>.deb</samp>
|
|
file) independently of whether or not the files on which it depends exist on
|
|
the system. Simplistically, unpacking means that <samp>dpkg</samp> 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 <em>depend</em> on the
|
|
existence of some other packages on your system, <samp>dpkg</samp> will refuse
|
|
to complete the installation (by executing its "configure" action)
|
|
until the other packages are installed.
|
|
</p>
|
|
|
|
<p>
|
|
However, for some packages, <samp>dpkg</samp> 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
|
|
<samp>a.out</samp> format to <samp>ELF</samp> format, where the <em>order</em>
|
|
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>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-pkgstatus"></a>6.11 What is meant by <em>unknown</em>, <em>install</em>, <em>remove</em> <em>purge</em> and <em>hold</em> in the package status?</h2>
|
|
|
|
<p>
|
|
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
|
|
<samp>dselect</samp>, or by the user's direct invocations of
|
|
<samp>dpkg</samp>).
|
|
</p>
|
|
|
|
<p>
|
|
Their meanings are:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
unknown - the user has never indicated whether he wants the package
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
install - the user wants the package installed or upgraded
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
remove - the user wants the package removed, but does not want to remove any
|
|
existing configuration files.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
purge - the user wants the package to be removed completely, including its
|
|
configuration files.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-puttingonhold"></a>6.12 How do I put a package on hold?</h2>
|
|
|
|
<p>
|
|
There are three ways of holding back packages, with dpkg, aptitude or with
|
|
dselect.
|
|
</p>
|
|
|
|
<p>
|
|
With dpkg, you just have to export the list of package selections, with:
|
|
</p>
|
|
|
|
<pre>
|
|
dpkg --get-selections \* > selections.txt
|
|
</pre>
|
|
|
|
<p>
|
|
Then edit the resulting file <code>selections.txt</code>, change the line
|
|
containing the package you wish to hold, e.g. <code>libc6</code>, from this:
|
|
</p>
|
|
|
|
<pre>
|
|
libc6 install
|
|
</pre>
|
|
|
|
<p>
|
|
to this:
|
|
</p>
|
|
|
|
<pre>
|
|
libc6 hold
|
|
</pre>
|
|
|
|
<p>
|
|
Save the file, and reload it into dpkg database with:
|
|
</p>
|
|
|
|
<pre>
|
|
dpkg --set-selections < selections.txt
|
|
</pre>
|
|
|
|
<p>
|
|
With aptitude, you can hold a package using
|
|
</p>
|
|
|
|
<pre>
|
|
aptitude hold package_name
|
|
</pre>
|
|
|
|
<p>
|
|
and remove the hold with
|
|
</p>
|
|
|
|
<pre>
|
|
aptitude unhold package_name
|
|
</pre>
|
|
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-sourcepkgs"></a>6.13 How do I install a source package?</h2>
|
|
|
|
<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
|
|
<code>sources.list(5)</code> to include the appropriate "deb-src"
|
|
lines, you'll be able to easily download any source packages by running
|
|
</p>
|
|
|
|
<pre>
|
|
apt-get source foo
|
|
</pre>
|
|
|
|
<p>
|
|
To help you in actually building the source package, Debian source package
|
|
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>
|
|
apt-get build-dep foo
|
|
</pre>
|
|
|
|
<p>
|
|
before building the source.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-sourcebuild"></a>6.14 How do I build binary packages from a source package?</h2>
|
|
|
|
<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 href="#s-sourcepkgs">How do I install a source package?,
|
|
Section 6.13</a>), if you have the <code>dpkg-dev</code> package installed, the
|
|
following command:
|
|
</p>
|
|
|
|
<pre>
|
|
dpkg-source -x foo_version-revision.dsc
|
|
</pre>
|
|
|
|
<p>
|
|
will extract the package into a directory called <samp>foo-version</samp>.
|
|
</p>
|
|
|
|
<p>
|
|
If you want just to compile the package, you may cd into
|
|
<samp>foo-version</samp> directory and issue the command
|
|
</p>
|
|
|
|
<pre>
|
|
dpkg-buildpackage -rfakeroot -b
|
|
</pre>
|
|
|
|
<p>
|
|
to build the package (note that this also requires the <code>fakeroot</code>
|
|
package), and then
|
|
</p>
|
|
|
|
<pre>
|
|
dpkg -i ../foo_version-revision_arch.deb
|
|
</pre>
|
|
|
|
<p>
|
|
to install the newly-built package(s).
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="s-creatingdebs"></a>6.15 How do I create Debian packages myself?</h2>
|
|
|
|
<p>
|
|
For more detailed description on this, read the New Maintainers' Guide,
|
|
available in the <code>maint-guide</code> package, or at <code><a
|
|
href="http://www.debian.org/doc/devel-manuals#maint-guide">http://www.debian.org/doc/devel-manuals#maint-guide</a></code>.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<p>
|
|
[ <a href="ch-ftparchives.en.html">previous</a> ]
|
|
[ <a href="index.en.html#contents">Contents</a> ]
|
|
[ <a href="ch-basic_defs.en.html">1</a> ]
|
|
[ <a href="ch-getting.en.html">2</a> ]
|
|
[ <a href="ch-compat.en.html">3</a> ]
|
|
[ <a href="ch-software.en.html">4</a> ]
|
|
[ <a href="ch-ftparchives.en.html">5</a> ]
|
|
[ 6 ]
|
|
[ <a href="ch-pkgtools.en.html">7</a> ]
|
|
[ <a href="ch-uptodate.en.html">8</a> ]
|
|
[ <a href="ch-kernel.en.html">9</a> ]
|
|
[ <a href="ch-customizing.en.html">10</a> ]
|
|
[ <a href="ch-support.en.html">11</a> ]
|
|
[ <a href="ch-contributing.en.html">12</a> ]
|
|
[ <a href="ch-redistrib.en.html">13</a> ]
|
|
[ <a href="ch-nexttime.en.html">14</a> ]
|
|
[ <a href="ch-faqinfo.en.html">15</a> ]
|
|
[ <a href="ch-pkgtools.en.html">next</a> ]
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<p>
|
|
The Debian GNU/Linux FAQ
|
|
</p>
|
|
|
|
<address>
|
|
version 3.1.3, 25 April 2006<br>
|
|
<br>
|
|
Authors are listed at <a href="ch-faqinfo.en.html#s-authors">Debian FAQ Authors</a><br>
|
|
<br>
|
|
</address>
|
|
<hr>
|
|
|
|
</body>
|
|
|
|
</html>
|
|
|