diff options
Diffstat (limited to 'templates/common/doc/FAQ/html/ch-pkg_basics.en.html')
| -rw-r--r-- | templates/common/doc/FAQ/html/ch-pkg_basics.en.html | 860 |
1 files changed, 860 insertions, 0 deletions
diff --git a/templates/common/doc/FAQ/html/ch-pkg_basics.en.html b/templates/common/doc/FAQ/html/ch-pkg_basics.en.html new file mode 100644 index 000000000..0ebd3feb3 --- /dev/null +++ b/templates/common/doc/FAQ/html/ch-pkg_basics.en.html @@ -0,0 +1,860 @@ +<!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> + |