Package: debian-faq Version: 5.0.1 Severity: minor Dear Maintainer, *** Please consider answering these questions, where appropriate ***
* What led up to the situation? found reference to 'user' as 'he' rather than 'he/she' in http://anonscm.debian.org/viewvc/ddp/manuals/trunk/debian-faq/pkg_basics.sgml?revision=7642 . Example: "individual user if he chooses." from line 90 * What exactly did you do (or not do) that was effective (or ineffective)? I modified the references * What was the outcome of this action? Please, find the diff attached here. -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash debian-faq depends on no packages. debian-faq recommends no packages. Versions of packages debian-faq suggests: ii epiphany-browser [www-browser] 3.4.2-2.1 ii evince [postscript-viewer] 3.4.0-3.1 ii ghostscript [postscript-viewer] 9.05~dfsg-6.3+deb7u1 ii google-chrome-stable [www-browser] 35.0.1916.153-1 ii gv [postscript-viewer] 1:3.7.3-1 ii iceweasel [www-browser] 24.6.0esr-1~deb7u1 ii w3m [www-browser] 0.5.3-8 -- no debconf information All the best, Myriam Leggieri
<!-- retain these comments for translator revision tracking -->
<!-- Original version: $Revision: 1.24 $ -->
<chapt id="pkg_basics">Basics of the Debian package management system
<p>This chapter touches on some lower level internals of Debian package
management. If you're interested mainly in <em>usage</em> of the relevant
tools, skip to chapters <ref id="pkgtools"> and/or <ref id="uptodate">.
<sect id="package">What is a Debian package?
<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:
<list>
<item><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 <ref id="deb-format">); they are usually distinguished by having
a '.deb' file extension. Binary packages can be unpacked using the Debian
utility <tt>dpkg</tt> (possibly via a frontend like <prgn/aptitude/);
details are given in its manual page.
<item><em>Source packages</em>, which consist of a <tt>.dsc</tt> file
describing the source package (including the names of the following
files), a <tt>.orig.tar.gz</tt> file that contains the original
unmodified source in gzip-compressed tar format and usually a
<tt>.diff.gz</tt> file that contains the Debian-specific changes to the
original source. The utility <tt>dpkg-source</tt> packs and unpacks
Debian source archives; details are provided in its manual page. (The
program <prgn/apt-get/ can get used a frontend for <tt>dpkg-source</tt>.)
</list>
<p>Installation of software by the package system uses "dependencies" which
are carefully designed by the package maintainers. These dependencies are
documented in the <tt>control</tt> file associated with each package.
For example, the package containing the GNU C compiler (<package/gcc/)
"depends" on the package <package/binutils/ which includes the linker and
assembler. If a user attempts to install <package/gcc/ without having first
installed <package/binutils/, the package management system (dpkg) will send
an error message that it also needs <package/binutils/, and stop installing
<package/gcc/. (However, this facility can be overridden by the insistent
user, see <manref name="dpkg" section="8">.) See more in <ref id="depends">
below.
<p>Debian's packaging tools can be used to:
<list>
<item>manipulate and manage packages or parts of packages,
<item>administer local overrides of files in a package,
<item>aid developers in the construction of package archives, and
<item>aid users in the installation of packages which reside on a remote
FTP site.
</list>
<sect id="deb-format">What is the format of a Debian binary package?
<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 <tt>.deb</tt>.
<p>The internals of this Debian binary packages format are described in the
<manref name="deb" section="5"> manual page. This internal format is subject to
change (between major releases of &debian;), therefore please always use
<manref name="dpkg-deb" section="1"> if you need to do lowlevel manipulations
on <tt>.deb</tt> files.
<sect id="pkgname">Why are Debian package file names so long?
<p>The Debian binary package file names conform to the following convention:
<foo>_<VersionNumber>-<DebianRevisionNumber>_<DebianArchitecture>.deb
<p>Note that <tt>foo</tt> 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:
<list>
<item>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.
<item>use the command <tt>dpkg --info foo_VVV-RRR_AAA.deb</tt> (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.
</list>
<p>The <tt>VVV</tt> 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>The <tt>RRR</tt> component is the Debian revision number, and is
specified by the Debian developer (or an individual user if he/she chooses
to build the package by himself/herself). This number corresponds to the revision
level of the Debian package, thus, a new revision level usually signifies
changes in the Debian Makefile (<tt>debian/rules</tt>), the Debian control
file (<tt>debian/control</tt>), the installation or removal scripts
(<tt>debian/p*</tt>), or in the configuration files used with the package.
<p>The <tt>AAA</tt> component identifies the processor for which
the package was built. This is commonly <tt>i386</tt>, which refers to
chips compatible to Intel's 386 or later versions. For other
possibilities review Debian's FTP directory structure at <ref id="dirtree">.
For details, see the description of "Debian architecture" in the manual page
<manref name="dpkg-architecture" section="1">.
<sect id="controlfile">What is a Debian control file?
<p>Specifics regarding the contents of a Debian control file are provided
in the Debian Policy Manual, section 5, see <ref id="debiandocs">.
<p>Briefly, a sample control file is shown below for the Debian package hello:
<example>
Package: hello
Priority: optional
Section: devel
Installed-Size: 45
Maintainer: Adam Heath <[email protected]>
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
<!-- XXX below 'non-programmers' were better, but this is a verbatim copy -->
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).
</example>
<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>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 <ref id="pkgname">. <!-- XXX missing name -->
<p>The Architecture field specifies the chip for which this particular
binary was compiled.
<p>The Depends field gives a list of packages that have to be
installed in order to install this package successfully.
<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>The Section line gives the "section" where this Debian package is stored
at the Debian FTP sites.
<p>The Priority indicates how important is this package for installation, so
that semi-intelligent software like dselect or aptitude can sort the
package into a category of e.g. packages optionally installed. See
<ref id="priority">.
<p>The Maintainer field gives the e-mail address of the person who is
currently responsible for maintaining this package.
<p>The Description field gives a brief summary of the package's features.
<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
<ref id="debiandocs">.
<sect id="conffile">What is a Debian conffile?
<p>Conffiles is a list of configuration files (usually placed in <tt>/etc</tt>)
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>To determine exactly which files are preserved during an upgrade, run:
<example>dpkg --status package</example>
And look under "Conffiles:".
<sect id="maintscripts">What is a Debian preinst, postinst, prerm, and postrm
script?
<p>These files are executable scripts which are automatically run before
or after a package is installed. Along with a file named <tt>control</tt>,
all of these files are part of the "control" section of a Debian archive file.
<p>The individual files are:
<taglist>
<tag/preinst/
<item>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).
<tag/postinst/
<item>This script typically completes any required configuration of the
package <tt>foo</tt> once <tt>foo</tt> 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/she accepts default values, he/she 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.
<tag/prerm/
<item>This script typically stops any daemons which are associated with
a package. It is executed before the removal of files associated with
the package.
<tag/postrm/
<item>This script typically modifies links or other files associated with
<tt>foo</tt>, and/or removes files created by the package. (Also see
<ref id="virtual">.)
</taglist>
<p>Currently all of the control files can be found in directory
<tt>/var/lib/dpkg/info</tt>. The files relevant to package <tt>foo</tt>
begin with the name "foo" and have file extensions of "preinst", "postinst",
etc., as appropriate. The file <tt>foo.list</tt> in that directory
lists all of the files that were installed with the package <tt>foo</tt>.
(Note that the location of these files is a dpkg internal; you should not
rely on it.)
<sect id="priority">What is an <em/Essential/, <em/Required/, <em/Important/, <em/Standard/,
<em/Optional/, or <em/Extra/ package?
<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:
<list>
<item><strong>Required</strong>: packages that are necessary for the proper
functioning of the system.
<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.
<item><strong>Important</strong> packages should be found on any Unix-like
system.
<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 X or TeX or any
other large applications. These packages only constitute the bare
infrastructure.
<item><strong>Standard</strong> 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 browse the web (using w3m), send e-mail
(with mutt) and download files from FTP servers.
<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
the Python interpreter and some server software like OpenSSH (for
remote administration), Exim (for mail delivery, although it can
be configured for local delivery only), an identd server (pidentd) and the
RPC portmapper (<tt>portmap</tt>). It also includes some common
generic documentation that most users will find helpful.
<item><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>This includes X, a full TeX distribution, and lots of applications.
<item><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".
</list>
<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>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.
<sect id="virtual">What is a Virtual Package?
<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 <tt>tin</tt> and <tt>trn</tt> 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
<tt>news-reader</tt>.
<p>Similarly, <tt>smail</tt> and <tt>sendmail</tt> 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 <tt>mail-transport-agent</tt> will be satisfied by
the existence of this virtual package.
<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 <tt>update-alternatives</tt>, and is described further in
<ref id="diverse">.
<sect id="depends">What is meant by saying that a package <em/Depends/,
<em/Recommends/, <em/Suggests/, <em/Conflicts/, <em/Replaces/, <em/Breaks/ or
<em/Provides/ another package?
<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:
<list>
<item>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.
<item>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.
<item>Package A <em>suggests</em> Package B if B contains files that
are related to (and usually enhance) the functionality of A.
<item>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".
<item>Package A <em>replaces</em> Package B when files installed
by B are removed and (in some cases) over-written by files in A.
<item>Package A <em>breaks</em> Package B when both cannot 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.
<item>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.
</list>
<p>More detailed information on the use of each these terms can be found
in the Debian Policy manual, section 7.2, "Binary Dependencies", see
<ref id="debiandocs">.
<sect id="pre-depends">What is meant by Pre-Depends?
<p>"Pre-Depends" is a special dependency. In the case of most packages,
<tt>dpkg</tt> will unpack its archive file (i.e., its <tt>.deb</tt> file)
independently of whether or not the files on which it depends exist on the
system. Simplistically, unpacking means that <tt>dpkg</tt> 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, <tt>dpkg</tt> will
refuse to complete the installation (by executing its "configure" action)
until the other packages are installed.
<p>However, for some packages, <tt>dpkg</tt> 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 <tt>a.out</tt> format to <tt>ELF</tt> 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>As before, more detailed information about this can be found in the
Policy manual.
<sect id="pkgstatus">What is meant by <em/unknown/, <em/install/, <em/remove/,
<em/purge/ and <em/hold/ in the package status?
<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
<tt>dselect</tt>, or by the user's direct invocations of <tt>dpkg</tt>).
<p>Their meanings are:
<list>
<item>unknown - the user has never indicated whether he/she wants the package
<item>install - the user wants the package installed or upgraded
<item>remove - the user wants the package removed, but does not want to
remove any existing configuration files.
<item>purge - the user wants the package to be removed completely,
including its configuration files.
<item>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.
</list>
<sect id="puttingonhold">How do I put a package on hold?
<p>There are three ways of holding back packages, with dpkg, aptitude
or with dselect.
<p>With dpkg, you have to export the list of package selections, with:
<example>dpkg --get-selections \* > selections.txt</example>
Then edit the resulting file <file/selections.txt/, change the line
containing the package you wish to hold, e.g. <package/libc6/, from this:
<example>libc6 install</example>
to this:
<example>libc6 hold</example>
Save the file, and reload it into dpkg database with:
<example>dpkg --set-selections < selections.txt</example>
<p>With aptitude, you can hold a package using
<example>aptitude hold package_name</example>
and remove the hold with
<example>aptitude unhold package_name</example>
<p>With dselect, you 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.
<sect id="sourcepkgs">How do I install a source package?
<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>Source packages are distributed on most of the same mirrors where you can
obtain the binary packages. If you set up your APT's
<manref name="sources.list" section="5"> to include the appropriate
"deb-src" lines, you'll be able to easily download any source packages
by running
<example>apt-get source foo</example>
<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
<example>apt-get build-dep foo</example>
before building the source.
<sect id="sourcebuild">How do I build binary packages from a source package?
<p>The preferred way to do this is by using various wrapper tools. We'll show
how it's done using the <tt>devscripts</tt> tools. Install this package if you
haven't done so already.
<p>Now, first get the source package:
<example>apt-get source foo</example>
and change to the source tree:
<example>cd foo-*</example>
Then install needed build-dependencies (if any):
<example>sudo apt-get build-dep foo</example>
Then create a dedicated version of your own build (so that you won't get
confused later when Debian itself releases a new version)
<example>dch -l local 'Blah blah blah'</example>
And finally build your package
<example>debuild -us -uc</example>
If everything worked out fine, you should now be able to install your
package by running
<example>sudo dpkg -i ../*.deb</example>
<p>If you prefer to do things manually, and don't want to use
<tt>devscripts</tt>, 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>Once you have them (<ref id="sourcepkgs">), if you have the
<package/dpkg-dev/ package installed,
the following command:
<example>dpkg-source -x foo_version-revision.dsc</example>
will extract the package into a directory called <tt>foo-version</tt>.
<p>If you want just to compile the package, you may cd into
<tt>foo-version</tt> directory and issue the command
<example>dpkg-buildpackage -rfakeroot -b</example>
to build the package (note that this also requires the
<package/fakeroot/ package), and then
<example>dpkg -i ../foo_version-revision_arch.deb</example>
to install the newly-built package(s).
<sect id="creatingdebs">How do I create Debian packages myself?
<p>For a more detailed description on this, read the New Maintainers' Guide,
available in the <package/maint-guide/ package, or at
<url id="http://www.debian.org/doc/devel-manuals#maint-guide";>.
signature.asc
Description: OpenPGP digital signature
