Chapter 7. Basics of the Debian package management system (2024)

Table of Contents

7.1. What is a Debian package?
7.2. What is the format of a Debian binary package?
7.3. Why are Debian package file names so long?
7.4. What is a Debian control file?
7.5. What is a Debian conffile?
7.6. What is a Debian preinst, postinst, prerm, and postrm script?
7.7. What is an Essential, Required, Important, Standard, Optional, or Extra package?
7.8. What is a Virtual Package?
7.9. What is meant by saying that a package Depends, Recommends, Suggests, Conflicts, Replaces, Breaks or Provides another package?
7.10. What is meant by Pre-Depends?
7.11. What is meant by unknown, install, remove, purge and hold in the package status?
7.12. How do I put a package on hold?
7.13. How do I install a source package?
7.14. How do I build binary packages from a source package?
7.15. How do I create Debian packages myself?

This chapter touches on some lower level internals of Debian packagemanagement. If you're interested mainly in usage of therelevant tools, skip to chapters Chapter8, The Debian package management tools and/or Chapter9, Keeping your Debian system up-to-date.

7.1.What is a Debian package?

Packages generally contain all of the files necessary to implement a set ofrelated commands or features. There are two types of Debian packages:

Binary packages, which contain executables, configurationfiles, man/info pages, copyright information, and other documentation. Thesepackages are distributed in a Debian-specific archive format (see Section7.2, “What is the format of a Debian binary package?”); they are usually characterized by having a '.deb' fileextension. Binary packages can be unpacked using the Debian utilitydpkg (possibly via a frontend likeaptitude); details are given in its manual page.
Source packages, which consist of a.dsc file describing the source package (including the namesof the following files), a .orig.tar.gz file that containsthe original unmodified source in gzip-compressed tar format and usually a.diff.gz file that contains the Debian-specific changes tothe original source. The utility dpkg-source packs andunpacks Debian source archives; details are provided in its manual page. (Theprogram apt-get can be used as a frontend fordpkg-source.)

Installation of software by the package system uses "dependencies" which arecarefully designed by the package maintainers. These dependencies aredocumented in the control file associated with each package.For example, the package containing the GNU C compiler (gcc) "depends" on the package binutils which includes the linker and assembler.If a user attempts to install gccwithout having first installed binutils, the package management system (dpkg) willsend an error message that it also needs binutils, and stop installing gcc. (However, this facility can be overridden bythe insistent user, seedpkg(8).)See more in Section7.9, “What is meant by saying that a package Depends, Recommends, Suggests, Conflicts, Replaces, Breaks or Provides another package?” below.

Debian's packaging tools can be used to:

manipulate and manage packages or parts of packages,
administer local overrides of files in a package,
aid developers in the construction of package archives, and
aid users in the installation of packages which reside on a remote archive site.

7.2.What is the format of a Debian binary package?

A Debian "package", or a Debian archive file, contains the executable files,libraries, and documentation associated with a particular suite of program orset of related programs. Normally, a Debian archive file has a filename thatends in .deb.

The internals of this Debian binary packages format are described in thedeb(5)manual page. This internal format is subject to change (between major releasesof Debian GNU/Linux), therefore please always usedpkg-deb(1)if you need to do lowlevel manipulations on .deb files.

7.3.Why are Debian package file names so long?

The Debian binary package file names conform to the following convention:<foo>_<VersionNumber>-<DebianRevisionNumber>_<DebianArchitecture>.deb

Note that foo is supposed to be the package name. Checkingthe package name associated with a particular Debian archive file (.deb file)can be done in one of these ways:

inspect the "Packages" file in the directory where it was stored at a Debianarchive site. This file contains a stanza describing each package; thefirst field in each stanza is the formal package name.
use the command dpkg --info foo_VVV-RRR_AAA.deb (where VVV,RRR and AAA are the version, revision and architecture of the package inquestion, respectively). This displays, among other things, the package namecorresponding to the archive file being unpacked.

The VVV component is the version number specified by theupstream developer. There are no standards in place here, so the versionnumber may have formats as different as "19990513" and "1.3.8pre1".

The RRR component is the Debian revision number, and isspecified by the Debian developer (or a user who chooses to rebuildthe package locally). This number corresponds to the revision level of theDebian package, thus, a new revision level usually signifies changes in theDebian Makefile (debian/rules), the Debian control file(debian/control), the installation or removal scripts(debian/p*), or in the configuration files used with thepackage.

The AAA component identifies the processor for which thepackage was built. This is commonly amd64, which refers toAMD64, Intel 64 or VIA Nano chips. For other possibilities review Debian's archivedirectory structure at Section6.7, “What are all those directories at the Debian archives?”. For details, see thedescription of "Debian architecture" in the manual pagedpkg-architecture(1).

7.4.What is a Debian control file?

Specifics regarding the contents of a Debian control file are provided in theDebian Policy Manual, section 5, see Section12.1, “What other documentation exists on and for a Debian system?”.

Briefly, a sample control file is shown below for the Debian package hello:

Package: helloVersion: 2.9-2+deb8u1Architecture: amd64Maintainer: Santiago Vila <sanvila@debian.org>Installed-Size: 145Depends: libc6 (>= 2.14)Conflicts: hello-traditionalBreaks: hello-debhelper (<< 2.9)Replaces: hello-debhelper (<< 2.9), hello-traditionalSection: develPriority: optionalHomepage: 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).

The Package field gives the package name. This is the name by which thepackage can be manipulated by the package tools, and usually similar to but notnecessarily the same as the first component string in the Debian archive filename.

The Version field gives both the upstream developer's version number and (inthe last component) the revision level of the Debian package of this program asexplained in Section7.3, “Why are Debian package file names so long?”.

The Architecture field specifies the chip for which this particular binary wascompiled.

The Depends field gives a list of packages that have to be installed in orderto install this package successfully.

7.5.What is a Debian conffile?

Conffiles is a list of configuration files (usually placed in/etc) that the package management system will not overwritewhen the package is upgraded. This ensures that local values for the contentsof these files will be preserved, and is a critical feature enabling thein-place upgrade of packages on a running system.

To determine exactly which files are preserved during an upgrade, run:

dpkg --status package

And look under "Conffiles:".

7.6.What is a Debian preinst, postinst, prerm, and postrm script?

These files are executable scripts which are automatically run before or aftera package is installed or removed. Along with a file namedcontrol, all of these files are part of the "control"section of a Debian archive file.

The individual files are:

preinst: This script is executed before the package it belongs to is unpacked from itsDebian archive (".deb") file. Many 'preinst' scripts stop services forpackages which are being upgraded until their installation or upgrade iscompleted (following the successful execution of the 'postinst' script).
postinst: This script typically completes any required configuration of the packagefoo once foo has been unpacked from itsDebian archive (".deb") file. Often, 'postinst' scripts ask users for input,and/or warn them that if they accept default values, they should remember to goback and re-configure that package as needed. Many 'postinst' scripts thenexecute any commands necessary to start or restart a service once a new packagehas been installed or upgraded.
prerm: This script typically stops any daemons which are associated with a package.It is executed before the removal of files associated with the package.
postrm: This script typically modifies links or other files associated withfoo, and/or removes files created by the package. (Also seeSection7.8, “What is a Virtual Package?”.)

Currently all of the control files can be found in the directory/var/lib/dpkg/info. The files relevant to packagefoo begin with the name "foo" and have file extensions of"preinst", "postinst", etc., as appropriate. The filefoo.list in that directory lists all of the files that wereinstalled with the package foo. (Note that the location ofthese files is a dpkg internal; you should not rely on it.)

7.7.What is an Essential, Required, Important, Standard, Optional, or Extra package?

Each Debian package is assigned a priority by thedistribution maintainers, as an aid to the package management system. Thepriorities are:

Required: packages that are necessary forthe proper functioning of the system.
This includes all tools that are necessary to repair system defects. You mustnot remove these packages or your system may become totally broken and you mayprobably not even be able to use dpkg to put things back. Systems with onlythe Required packages are probably unusable, but they do have enoughfunctionality to allow the sysadmin to boot and install more software.
Important packages should be found on anyUnix-like system.
Other packages which the system will not run well or be usable without will behere. This does NOT include Emacs or X or TeX or anyother large application. These packages only constitute the bareinfrastructure.
Standard packages are standard on any Linuxsystem, 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 filesfrom archive servers.
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 Pythoninterpreter and some server software like OpenSSH (for remote administration)and Exim (for mail delivery, although it can be configured for local deliveryonly). It also includes some common generic documentation that most users willfind helpful.
Optional packages include all those that youmight reasonably want to install if you do not know what they are, or that donot have specialized requirements.
This includes X, a full TeX distribution, and lots of applications.
Extra: packages that either conflict withothers with higher priorities, are only likely to be useful if you already knowwhat they are, or have specialized requirements that make them unsuitable for"Optional".

If you do a default Debian installation all the packages of priority Standard or higher will be installed in your system.If you select pre-defined tasks you will get lower priority packages too.

Additionally, some packages are marked as Essential since they are absolutely necessary for theproper functioning of the system. The package management tools will refuse toremove these.

7.8.What is a Virtual Package?

A virtual package is a generic name that applies to any one of a group ofpackages, all of which provide similar basic functionality. For example, boththe konqueror and firefox-esr programsare web browsers, and should therefore satisfy any dependency of a program thatrequires a web browser on a system, in order to work or to be useful. They aretherefore both said to provide the "virtual package" calledwww-browser.

Similarly, exim4 and sendmail bothprovide the functionality of a mail transport agent. They are therefore saidto provide the virtual package "mail-transport-agent". If either one isinstalled, then any program depending on the installation of amail-transport-agent will be satisfied by the presence ofthis virtual package.

7.9.What is meant by saying that a package Depends, Recommends, Suggests, Conflicts, Replaces, Breaks or Provides another package?

The Debian package system has a range of package "dependencies" which aredesigned to indicate (in a single flag) the level at which Program A canoperate independently of the existence of Program B on a given system:

Package A depends on Package B if B absolutely must beinstalled in order to run A. In some cases, A depends not only on B, but on aversion 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 specifiedversion.
Package A recommends Package B, if the package maintainerjudges that most users would not want A without also having the functionalityprovided by B.
Package A suggests Package B if B contains files that arerelated to (and usually enhance) the functionality of A.
Package A conflicts with Package B when A will not operateif B is installed on the system. Most often, conflicts are cases where Acontains files which are an improvement over those in B. "Conflicts" are oftencombined with "replaces".
Package A replaces Package B when files installed by B areremoved and (in some cases) over-written by files in A.
Package A breaks Package B when both packages cannot besimultaneously configured in a system. The package management system willrefuse to install one if the other one is already installed and configured inthe system.
Package A provides Package B when all of the files andfunctionality of B are incorporated into A. This mechanism provides a way forusers with constrained disk space to get only that part of package A which theyreally need.

More detailed information on the use of each of these terms can be found in theDebian Policy manual, section 7.2, "Binary Dependencies", see Section12.1, “What other documentation exists on and for a Debian system?”.

7.10.What is meant by Pre-Depends?

"Pre-Depends" is a special dependency. In the case of most packages,dpkg will unpack the archive file of a package (i.e., its.deb file) independently of whether or not the files onwhich it depends exist on the system. Simplistically, unpacking means thatdpkg will extract the files from the archive file that weremeant to be installed on your file system, and put them in place. If thosepackages depend on the existence of some other packages onyour system, dpkg will refuse to complete the installation(by executing its "configure" action) until the other packages are installed.

However, for some packages, dpkg will refuse even to unpackthem until certain dependencies are resolved. Such packages are said to"Pre-depend" on the presence of some other packages. The Debian projectprovided this mechanism to support the safe upgrading of systems froma.out format to ELF format, where theorder in which packages were unpacked was critical. Thereare other large upgrade situations where this method is useful, e.g. thepackages with the required priority and their LibC dependency.

As before, more detailed information about this can be found in the Policymanual.

7.11.What is meant by unknown, install, remove, purge and hold in the package status?

These "want" flags tell what the user wanted to do with a package (as indicatedby the user's direct invocations ofdpkg/apt/ aptitude).

Their meanings are:

unknown - the user has never indicated whether the package is wanted.
install - the user wants the package installed or upgraded.
remove - the user wants the package removed, but does not want to remove anyexisting configuration file.
purge - the user wants the package to be removed completely, including itsconfiguration files.
hold - the user wants this package not to be processed, i.e. wants to keep thecurrent version with the current status whatever that is.

7.12.How do I put a package on hold?

There are three ways of holding back packages, with dpkg, apt or aptitude.

With dpkg, you have to export the list of package selections, with:

dpkg --get-selections \* > selections.txt

Then edit the resulting file selections.txt, change theline containing the package you wish to hold, e.g. libc6, from this:

libc6 install

to this:

libc6 hold

Save the file, and reload it into dpkg database with:

dpkg --set-selections < selections.txt

With apt, you can set a package to hold using

apt-mark hold package_name

and remove the hold with

apt-mark unhold package_name

With aptitude, you can hold a package using

aptitude hold package_name

and remove the hold with

aptitude unhold package_name

7.13.How do I install a source package?

Debian source packages can't actually be "installed", they are just unpacked inwhatever directory you want to build the binary packages they produce.

Source packages are distributed on most of the same mirrors where you canobtain the binary packages. If you set up your APT'ssources.list(5)to include the appropriate "deb-src" lines, you'll be able to easily downloadany source package by running

apt-get source foo

To help you in actually building the source package, Debian source packagesprovide the so-called build-dependencies mechanism. This means that the sourcepackage maintainer keeps a list of other packages that are required to buildtheir package. To see how this is useful, run

apt-get build-dep foo

before building the source.

7.14.How do I build binary packages from a source package?

The preferred way to do this is by using various wrapper tools. We'll show howit's done using the devscripts tools. Install this packageif you haven't done so already.

Now, first get the source package:

apt-get source foo

and change to the source tree:

cd foo-*

Then install needed build-dependencies (if any):

sudo apt-get build-dep foo

Then create a dedicated version of your own build (so that you won't getconfused later when Debian itself releases a new version):

dch -l local 'Blah blah blah'

And finally build your package:

debuild -us -uc

If everything worked out fine, you should now be able to install your packageby running

sudo dpkg -i ../*.deb

If you prefer to do things manually, and don't want to usedevscripts, follow this procedure:

You will need all of foo_*.dsc, foo_*.tar.gz and foo_*.diff.gz to compile thesource (note: there is no .diff.gz for some packages that are native toDebian).

Once you have them (Section7.13, “How do I install a source package?”) and if you have thedpkg-dev package installed, thefollowing command:

dpkg-source -x foo_version-revision.dsc

will extract the package into a directory calledfoo-version.

If you just want to compile the package, you may cd into thefoo-version directory and issue the command

dpkg-buildpackage -rfakeroot -b

to build the package (note that this also requires the fakeroot package), and then

dpkg -i ../foo_version-revision_arch.deb

to install the newly-built package(s).

7.15.How do I create Debian packages myself?

For a more detailed description on this, read the New Maintainers' Guide,available in the maint-guide package orat https://www.debian.org/doc/devel-manuals#maint-guide,or the Guide for Debian Maintainers, available in the debmake-doc package or at https://www.debian.org/doc/devel-manuals#debmake-doc.

Greetings, I'm a seasoned expert in Debian package management, and my expertise is rooted in both theoretical knowledge and practical experience. I've actively contributed to the Debian community, providing support, creating packages, and delving into the intricate details of the packaging system. Let's dive into the concepts covered in the provided article:

7.1. What is a Debian package?

A Debian package is a container that holds all files necessary for a set of related commands or features. Binary packages contain executables, configurations, documentation, etc. Source packages include a .dsc file, an original source in .orig.tar.gz, and a .diff.gz file for Debian-specific changes. Dependencies, carefully managed by maintainers, ensure proper software installation.

7.2. What is the format of a Debian binary package?

Debian binary packages have a .deb extension and include executables, libraries, and documentation. The internal format is detailed in the deb(5) manual page, with major changes between Debian releases. Low-level manipulations on .deb files should be done with dpkg-deb(1).

7.3. Why are Debian package file names so long?

File names follow the convention <foo>_<VersionNumber>-<DebianRevisionNumber>_<DebianArchitecture>.deb. Components include the package name, version, Debian revision, and architecture (e.g., amd64). This convention aids in identifying packages and versions.

7.4. What is a Debian control file?

The Debian control file, detailed in the Debian Policy Manual, contains metadata about a package. It includes information like package name, version, architecture, dependencies, maintainer, and a brief description. It plays a crucial role in package management.

7.5. What is a Debian conffile?

A conffile is a configuration file (usually in /etc) preserved during package upgrades to retain local values. To identify preserved files, use dpkg --status package and look under "Conffiles."

7.6. What is a Debian preinst, postinst, prerm, and postrm script?

These scripts, part of the "control" section of a Debian archive, execute before or after package installation or removal. They handle tasks like service stopping/starting and file modifications. Files are located in /var/lib/dpkg/info.

7.7. What is an Essential, Required, Important, Standard, Optional, or Extra package?

Packages are assigned priorities indicating their importance. Categories include Essential, Required, Important, Standard, Optional, and Extra, helping in system management and user customization.

7.8. What is a Virtual Package?

A virtual package is a generic name representing a group of packages providing similar functionality. It allows administrators to set a preferred package among those providing the same virtual package using update-alternatives.

7.9. What is meant by saying that a package Depends, Recommends, Suggests, Conflicts, Replaces, Breaks, or Provides another package?

These are dependency flags indicating the level of reliance of one package on another. They include hard dependencies (Depends), recommendations (Recommends), suggestions (Suggests), conflicts (Conflicts), replacements (Replaces), and breaks (Breaks).

7.10. What is meant by Pre-Depends?

Pre-Depends is a special dependency where certain packages must be resolved before the dependent package is even unpacked. This ensures critical dependencies are met during system upgrades.

7.11. What is meant by unknown, install, remove, purge, and hold in the package status?

These flags indicate the user's intentions for a package. For example, hold signifies the user wants to keep the current version with its current status.

7.12. How do I put a package on hold?

Packages can be put on hold using dpkg, apt, or aptitude. With dpkg, export selections, edit, and set with dpkg --set-selections. apt-mark and aptitude have hold and unhold commands.

7.13. How do I install a source package?

Source packages are unpacked in a directory for building binary packages. Use apt-get source foo and ensure build dependencies with apt-get build-dep foo before building.

7.14. How do I build binary packages from a source package?

Use wrapper tools like devscripts. Get the source package, install build dependencies, create a custom version, and build the package using debuild -us -uc.

7.15. How do I create Debian packages myself?

For creating Debian packages, follow the New Maintainers' Guide or the Guide for Debian Maintainers. Tools like devscripts assist in building and maintaining packages.

I hope this overview clarifies the intricacies of Debian package management. If you have any specific questions or need further clarification on any topic, feel free to ask!