Maintenance and Updates: The APT Tools

What makes Debian so popular with administrators is how easily software can be installed and how easily the whole system can be updated. This unique advantage is largely due to the APT program, which Falcot Corp administrators studied with enthusiasm.

APT

Advanced Packaging Tool

APT

APT is the abbreviation for Advanced Packaging Tool. What makes this program “advanced” is its approach to packages. It doesn't simply evaluate them individually, but it considers them as a whole and produces the best possible combination of packages depending on what is available and compatible according to dependencies.

APT needs to be given a “list of package sources (repositories)”: the file /etc/apt/sources.list will list the different repositories that publish Debian packages. APT will then import the list of packages published by each of these sources. This operation is achieved by downloading Packages.xz files or a variant such as Packages.gz or .bz2 (using a different compression method) in case of a source of binary packages and by analyzing their contents. In case of a source of source packages, APT downloads Sources.xz files or a variant using a different compression method. When an old copy of these files is already present, APT can update it by only downloading the differences (see sidebar sidebar_title).

Packages.xz

Packages.gz

Packages.bz2

Sources.xz

Sources.gz

Sources.bz2

Filling in the sources.list File

sources.list

source

of packages

package

source of

APT

/etc/apt/sources.list

sources.list

Syntax

Each active line in the /etc/apt/sources.list file represents a package source (repository) and is made of at least three parts separated by spaces. For a complete description of the file format and the accepted entry compositions see sources.list(5).

deb url distribution component1 component2 component3 [..] componentX
deb-src url distribution component1 component2 component3 [..] componentX

The first field indicates the source type:

deb
package source (repository) of binary packages

deb-src
package source (repository) of source packages

The second field gives the base URL of the source. Combined with the filenames listed in the Packages.xz files, it must give a full and valid URL. This can consist in a Debian mirror or in any other package archive set up by a third party. The URL can start with file:// to indicate a local source installed in the system's file hierarchy, with http:// or https:// to indicate a source accessible from a web server, or with ftp:// or ftps:// for a source available on an FTP server. The URL can also start with cdrom: for CD-ROM/DVD/Blu-ray disc based installations, although this is less frequent, since network-based installation methods are eventually more common. More methods like ssh:// or tor+http(s):// are supported and are either described in sources.list(5) or their respective apt-transport-<method> package documentation.

The syntax of the last field depends on the structure of the repository. In the simplest case, you can simply indicate a subdirectory (with a required trailing slash) of the desired source. This is often a simple “./” which refers to the absence of a subdirectory. The packages are then directly at the specified URL. But in most common cases, the repositories will be structured like a Debian mirror, with multiple distributions, each having multiple components. In those cases, name the chosen distribution by its “codename” — see the list in sidebar ??? — or by the corresponding “suite” (oldoldstable, oldstable, stable, testing, unstable) and then the components to enable. A typical Debian mirror provides the components main, contrib, non-free, and non-free-firmware.

apt-cdrom

The cdrom entries describe the CD/DVD-ROMs you have. Contrary to other entries, a CD-ROM is not always available since it has to be inserted into the drive and since only one disc can be read at a time. For those reasons, these sources are managed in a slightly different way, and need to be added with the apt-cdrom program, usually executed with the add parameter. The latter will then request the disc to be inserted in the drive and will browse its contents looking for Packages files. It will use these files to update its database of available packages (this operation is usually done by the apt update command). From then on, APT can require the disc to be inserted if it needs one of its packages.

Repositories for Stable Users

sources.list

stable

stable

stable-security

stable-backports

stable-updates

bookworm

bookworm-security

bookworm-backports

bookworm-updates

Here is a standard sources.list for a system running the Stable version of Debian:

# Security updates
deb http://security.debian.org/ bookworm-security main contrib non-free non-free-firmware
deb-src http://security.debian.org/ bookworm-security main contrib non-free non-free-firmware

## Debian mirror

# Base repository
deb https://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
deb-src https://deb.debian.org/debian bookworm main contrib non-free non-free-firmware

# Stable updates
deb https://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
deb-src https://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware

# Stable backports
deb https://deb.debian.org/debian bookworm-backports main contrib non-free non-free-firmware
deb-src https://deb.debian.org/debian bookworm-backports main contrib non-free non-free-firmware

This file lists all sources of packages associated with the Bookworm version of Debian (the current Stable suite as of this writing). In the example above, we opted to name “bookworm” explicitly instead of using the corresponding “stable“ aliases (stable, stable-updates, stable-backports) because we don't want to have the underlying distribution changed outside of our control when the next stable release comes out.

Most packages will come from the “base repository”, which contains all packages but is seldom updated (about once every 2 months for a “point release”). The other repositories are partial (they do not contain all packages) and can host updates (packages with newer version) that APT might install. The following sections will explain the purpose and the rules governing each of those repositories.

Note that when the desired version of a package is available on several repositories, the first one listed in the sources.list file will be used. For this reason, non-official sources are usually added at the end of the file.

As a side note, most of what this section says about Stable applies equally well to Oldstable since the latter is just an older Stable that is maintained in parallel.

Security Updates

security.debian.org

security

updates

updates

security updates

updates

stable-security

updates

bookworm-security

updates

stable

, security

updates

bookworm

, security

stable-security

bookworm-security

CVE

Common Vulnerabilities and Exposures

Common Vulnerabilities and Exposures

CVE

Debian takes security seriously. Known software vulnerabilities in Debian are tracked in the Security Bug Tracker and usually get fixed in a reasonable timeframe. The security updates are not hosted on the usual network of Debian mirrors but on security.debian.org, a small set of machines maintained by the Debian System Administrators. This archive contains security updates prepared by the Debian Security Team and/or by package maintainers for the Stable and Oldstable distribution.

The server can also host security updates for Testing but this doesn't happen very often since those updates tend to reach that suite via the regular flow of updates coming from Unstable.

DSA

Debian Security Advisory

Debian Security Advisory

For serious issues, the security team issues a Debian Security Advisory (DSA) and announces it together with the security update on the debian-security-announce@lists.debian.org mailing list (archive).

mailing lists

debian-security-announce@lists.debian.org

Stable Updates

stable updates

updates

stable

updates

bookworm

stable-updates

bookworm-updates

Stable updates are not security sensitive but are deemed important enough to be pushed to users before the next stable point release.

This repository will typically contain fixes for critical and serious bugs which could not be fixed before release or which have been introduced by subsequent updates. Depending on the urgency, it can also contain updates for packages that have to evolve over time, like spamassassin's spam detection rules, clamav's virus database, the daylight-saving time rules of all timezones (tzdata), the ESR version of Firefox (firefox-esr) or cryptographic keyrings like debian-archive-keyring.

ESR

Extended Support Release

Extended Support Release

In practice, this repository is a subset of the proposed-updates repository, carefully selected by the Stable Release Managers. All updates are announced on the debian-stable-announce@lists.debian.org mailing list (archive) and will be included in the next Stable point release anyway.

mailing lists

debian-stable-announce@lists.debian.org

Proposed Updates

proposed updates

proposed-updates

stable-proposed-updates

bookworm-proposed-updates

updates

proposed

updates

stable-proposed

updates

bookworm-proposed

updates

stable

, proposed

updates

bookworm

, proposed

stable-updates

, proposed

bookworm-updates

, proposed

Once published, the Stable distribution is only updated about once every 2 months. The proposed-updates repository is where the expected updates are prepared (under the supervision of the Stable Release Managers).

The security and stable updates documented in the former sections are always included in this repository, but there is more too, because package maintainers also have the opportunity to fix important bugs that do not deserve an immediate release.

Anyone can use this repository to test those updates before their official publication. The extract below uses the bookworm-proposed-updates alias which is both more explicit and more consistent since bullseye-proposed-updates also exists (for the Oldstable updates):

deb https://deb.debian.org/debian bookworm-proposed-updates main contrib non-free non-free-firmware

Stable Backports

backport

updates

backports

updates

stable-backports

updates

bookworm-backports

updates

stable

, backports

updates

bookworm

, backports

stable-backports

bookworm-backports

The stable-backports repository hosts “package backports”. The term refers to a package of some recent software which has been recompiled for an older distribution, generally for Stable.

When the distribution becomes a little dated, numerous software projects have released new versions that are not integrated into the current Stable suite, which is only modified to address the most critical problems, such as security issues. Since the Testing and Unstable suites can be more risky, package maintainers sometimes voluntarily offer recompilations of recent software applications for Stable, which has the advantage to users and system administrators to limit potential instability to a small number of chosen packages. The page provides more information.

backports.debian.org

backports

Backports from stable-backports are only created from packages available in Testing. This ensures that all installed backports will be upgradable to the corresponding stable version once the next stable release of Debian is available.

Even though this repository provides newer versions of packages, APT will not install them unless you give explicit instructions to do so (or unless you have already done so with a former version of the given backport):

$ sudo apt-get install package/bookworm-backports
$ sudo apt-get install -t bookworm-backports package

Repositories for Testing/Unstable Users

sources.list

testing

sources.list

unstable

Here is a standard sources.list for a system running the Testing or Unstable version of Debian:

# Unstable
deb https://deb.debian.org/debian unstable main contrib non-free non-free-firmware
deb-src https://deb.debian.org/debian unstable main contrib non-free non-free-firmware

# Testing
deb https://deb.debian.org/debian testing main contrib non-free non-free-firmware
deb-src https://deb.debian.org/debian testing main contrib non-free non-free-firmware

# Testing security updates
deb http://security.debian.org/ testing-security main contrib non-free non-free-firmware
deb-src http://security.debian.org/ testing-security main contrib non-free non-free-firmware

# Stable
deb https://deb.debian.org/debian stable main contrib non-free non-free-firmware
deb-src https://deb.debian.org/debian stable main contrib non-free non-free-firmware

# Stable security updates
deb http://security.debian.org/ stable-security main contrib non-free non-free-firmware
deb-src http://security.debian.org/ stable-security main contrib non-free non-free-firmware

APT

APT::Default-Release

With this sources.list file APT will install packages from the Unstable suite. If that is not desired, use the APT::Default-Release setting (see System Upgrade) to instruct APT to pick packages from another suite (most likely Testing in this case).

There are good reasons to include all those repositories, even though a single one should be enough. Testing users will appreciate the possibility to cherry-pick a fixed package from Unstable when the version in Testing is affected by an annoying bug. On the other hand, Unstable users bitten by unexpected regressions have the possibility to downgrade packages to their (supposedly working) Testing version.

The inclusion of Stable is more debatable, but it often provides access to some packages, which have been removed from the development versions. It also ensures that you get the latest updates for packages, which have not been modified since the last stable release.

The Experimental Repository

The archive of Experimental packages is present on all Debian mirrors, and contains packages which are not in the Unstable version yet because of their substandard quality — they are often software development versions or pre-versions (alpha, beta, release candidate…). A package can also be sent there after undergoing subsequent changes which can generate problems. The maintainer then tries to uncover them with help from advanced users who can handle important issues. After this first stage, the package is moved into Unstable, where it reaches a much larger audience and where it will be tested in much more detail.

Experimental is generally used by users who do not mind breaking their system and then repairing it. This distribution gives the possibility to import a package which a user wants to try or use as the need arises. That is exactly how Debian approaches it, since adding it in APT's sources.list file does not lead to the systematic use of its packages. The line to be added is:

deb https://deb.debian.org/debian experimental main contrib non-free non-free-firmware

Using Alternate Mirrors

deb.debian.org

mirrors

mirrors

deb.debian.org

mirrors

CDN

Content Delivery Networks

Content Delivery Networks

The sources.list examples in this chapter refer to package repositories hosted on deb.debian.org. Those URLs will redirect you to servers which are close to you and which are managed by Content Delivery Networks (CDN) whose main role is to store multiple copies of the files across the world, and to deliver them as fast as possible to users. The CDN companies that Debian is working with are Debian partners who are offering their services freely to Debian. While none of those servers are under direct control of Debian, the fact that the whole archive is sealed by GPG signatures makes it a non-issue.

mirror list

mirrors

list of mirrors

mirrors

Picky users who are not satisfied with the performance of deb.debian.org can try to find a better mirror in the official mirror list:

mirrors

ftp.

country-code

.debian.org

But when you don't know which mirror is best for you, this list is of not much use. Fortunately for you, Debian maintains DNS entries of the form ftp.country-code.debian.org (e.g. ftp.us.debian.org for the USA, ftp.fr.debian.org for France, etc.) which are covering many countries and which are pointing to one (or more) of the best mirrors available within that country.

httpredir.debian.org

mirrors

mirrors

httpredir.debian.org

mirrors

deb.debian.org

As an alternative to deb.debian.org, there used to be httpredir.debian.org. This service would identify a mirror close to you (among the list of official mirrors, using GeoIP mainly) and would redirect APT's requests to that mirror. This service has been deprecated due to reliability concerns and now httpredir.debian.org provides the same CDN-based service as deb.debian.org.

Non-Official Resources: mentors.debian.net

mentors.debian.net

There are numerous non-official sources of Debian packages set up by advanced users who have recompiled some software — Ubuntu made this popular with their Personal Package Archive (PPA) service — by programmers who make their creation available to all, and even by Debian developers who offer pre-versions of their package online.

The mentors.debian.net site is interesting (although it only provides source packages), since it gathers packages created by candidates to the status of official Debian developer or by volunteers who wish to create Debian packages without going through that process of integration. These packages are made available without any guarantee regarding their quality; make sure that you check their origin and integrity and then test them before you consider using them in production.

Installing a package means giving root rights to its creator, because they decide on the contents of the initialization scripts which are run under that identity. Official Debian packages are created by volunteers who have been co-opted and reviewed and who can seal their packages so that their origin and integrity can be checked.

In general, be wary of a package whose origin you don't know and which isn't hosted on one of the official Debian servers: evaluate the degree to which you can trust the creator, and check the integrity of the package.

Caching Proxy for Debian Packages

proxy cache

cache, proxy

When an entire network of machines is configured to use the same remote server to download the same updated packages, any administrator knows that it would be beneficial to have an intermediate proxy acting as a network-local cache (see sidebar sidebar_title).

You can configure APT to use a "standard" proxy (see Configuration Options for the APT side, and ??? for the proxy side), but the Debian ecosystem offers better options to solve this problem. The dedicated software presented in this section are smarter than a plain proxy cache because they can rely on the specific structure of APT repositories (for instance they know when individual files are obsolete or not, and thus adjust the time during which they are kept).

apt-cacher and apt-cacher-ng work like usual proxy cache servers. APT's sources.list is left unchanged, but APT is configured to use them as proxy for outgoing requests.

/etc

/etc/approx/approx.conf

approx, on the other hand, acts like an HTTP server that “mirrors” any number of remote repositories in its top-level URLs. The mapping between those top-level directories and the remote URLs of the repositories is stored in /etc/approx/approx.conf:

# <name>   <repository-base-url>
debian     https://deb.debian.org/debian
security   http://security.debian.org/debian-security

approx runs by default on port 9999 via a systemd socket and requires the users to adjust their sources.list file to point to the approx server:

# Sample sources.list pointing to a local approx server
deb http://localhost:9999/security bookworm-security main contrib non-free non-free-firmware
deb http://localhost:9999/debian   bookworm main contrib non-free non-free-firmware

aptitude, apt-get, and apt Commands

apt

apt-get

aptitude

APT is a vast project, whose original plans included a graphical interface. It is based on a library which contains the core application, and apt-get is the first front end — command-line based — which was developed within the project. apt is a second command-line based front end provided by APT which overcomes some design mistakes of apt-get.

Both tools are built on top of the same library and are thus very close, but the default behavior of apt has been improved for interactive use and to actually do what most users expect. The APT developers reserve the right to change the public interface of this tool to further improve it. Conversely, the public interface of apt-get is well defined and will not change in any backwards incompatible way. It is thus the tool that you want to use when you need to script package installation requests.

synaptic

wajig

Numerous other graphical interfaces then appeared as external projects: synaptic, aptitude (which includes both a text mode interface and a graphical one — even if not complete yet), wajig, etc. The most recommended interface, apt, is the one that we will use in the examples given in this section. Note, however, that apt-get and aptitude have a very similar command line syntax. When there are major differences between these three commands, these will be detailed.

Initialization

For any work with APT, the list of available packages needs to be updated; this can be done simply through apt update. Depending on the speed of your connection and configuration, the operation can take a while, since it involves downloading a certain number of (usually compressed) files (Packages, Sources, Translation-language-code), which have gradually become bigger and bigger as Debian has developed (at least 14-18 MB of data for the main section). Of course, installing from a CD-ROM/DVD set does not require any downloading — in this case, the operation is very fast.

apt

update

apt-get

update

aptitude

update

APT

update package list

$ sudo apt -o "Acquire::PDiffs=false" update

Installing and Removing

APT

package installation

APT

package removal

APT

package purge

package

installation

package

removal

package

purge

installation

package installation

removal of a package

With APT, packages can be added or removed from the system, respectively with apt install package and apt remove package. In both cases, APT will automatically install the necessary dependencies or delete the packages which depend on the package that is being removed. The apt purge package command involves a complete uninstallation by deleting the configuration and data files as well.

apt

install

apt

remove

apt

purge

apt-get

install

apt-get

remove

apt-get

purge

aptitude

install

aptitude

remove

aptitude

purge

$ dpkg --get-selections >pkg-list

## Update dpkg's database of known packages
# avail=`mktemp`
# apt-cache dumpavail > "$avail"
# dpkg --merge-avail "$avail"
# rm -f "$avail"
## Update dpkg's selections
# dpkg --set-selections < pkg-list
## Ask apt-get to install the selected packages
# apt-get dselect-upgrade

# apt install package1 package2-

# apt remove package1+ package2

# apt --reinstall install postfix

# apt --reinstall -o Dpkg::Options::="--force-confask,confmiss" install package

apt

install

package

=

version

apt

install

package

/

distribution

apt-get

install

package

=

version

apt-get

install

package

/

distribution

If the file sources.list mentions several distributions, it is possible to give the version of the package to install. A specific version number can be requested with apt install package=version, but indicating its distribution of origin (Stable, Testing or Unstable) — with apt install package/distribution — is usually preferred. With this command, it is possible to go back to an older version of a package (if, for instance, you know that it works well), provided that it is still available in one of the sources referenced by the sources.list file. Otherwise the snapshot.debian.org archive can come to the rescue (see sidebar sidebar_title).

# apt install spamassassin/unstable

apt

install

apt-get

install

.deb

If the package to install has been made available to you under the form of a simple .deb file without any associated package repository, it is still possible to use APT to install it together with its dependencies (provided that the dependencies are available in the configured repositories) with a simple command: apt install ./path-to-the-package.deb. The leading ./ is important to make it clear that we are referring to the name of a file and not to the name of a package available in one of the repositories.

System Upgrade

upgrade

system upgrade

APT

system update

package

upgrade

apt

upgrade

apt-get

upgrade

aptitude

safe-upgrade

Regular upgrades are recommended, because they include the latest security updates. To upgrade, use apt upgrade, apt-get upgrade or aptitude safe-upgrade (of course after apt update). This command looks for installed packages which can be upgraded without removing any packages. In other words, the goal is to ensure the least intrusive upgrade possible. apt-get is slightly more demanding than aptitude or apt because it will refuse to install packages which were not installed beforehand.

apt will generally select the most recent version number (except for packages from Experimental and stable-backports, which are ignored by default whatever their version number). If you specified Testing or Unstable in your sources.list, apt upgrade will switch most of your Stable system to Testing or Unstable, which might not be what you intended.

APT

APT::Default-Release

APT

/etc/apt/apt.conf

To tell apt to use a specific distribution when searching for upgraded packages, you need to use the -t or --target-release option, followed by the name of the distribution you want (for example, apt -t stable upgrade). To avoid specifying this option every time you use apt, you can add APT::Default-Release "stable"; in the file /etc/apt/apt.conf.d/local.

APT

system upgrade

apt

full-upgrade

apt

dist-upgrade

apt-get

dist-upgrade

aptitude

full-upgrade

aptitude

dist-upgrade

For more important upgrades, such as the change from one major Debian version to the next, you need to use apt full-upgrade. With this instruction, apt will complete the upgrade even if it has to remove some obsolete packages or install new dependencies. This is also the command used by users who work daily with the Debian Unstable release and follow its evolution day by day. It is so simple that it hardly needs explanation: APT's reputation is based on this great functionality.

Unlike apt and aptitude, apt-get doesn't know the full-upgrade command. Instead, you should use apt-get dist-upgrade (”distribution upgrade”), the historical and well-known command that apt and aptitude also accept for the convenience of users who got used to it.

/var

/var/log/apt/

APT

APT

/var/log/apt/history.log

APT

/var/log/apt/term.log

APT

/var/log/apt/eipp.log.xz

dpkg

/var/log/dpkg.log

/var

/var/log/dpkg.log

The results of these operations are logged into /var/log/apt/history.log and /var/log/apt/term.log, whereas dpkg keeps its log in a file called /var/log/dpkg.log.

Configuration Options

apt.conf

APT

configuration

APT

/etc/apt/apt.conf

APT

/etc/apt/apt.conf.d/

APT

Dpkg::Options

APT

Acquire::http::proxy

APT

Acquire::ftp::proxy

Besides the configuration elements already mentioned, it is possible to configure certain aspects of APT by adding directives in a file of the /etc/apt/apt.conf.d/ directory or /etc/apt/apt.conf itself. Remember, for instance, that it is possible for APT to tell dpkg to ignore file conflict errors by specifying DPkg::options { "--force-overwrite"; }.

If the Web can only be accessed through a proxy, add a line like Acquire::http::proxy "http://yourproxy:3128". For an FTP proxy, write Acquire::ftp::proxy "ftp://yourproxy". To discover more configuration options, read the apt.conf(5) manual page (for details on manual pages, see ???).

Managing Package Priorities

pinning, APT pinning

package

priority

priority

package priority

One of the most important aspects in the configuration of APT is the management of the priorities associated with each package source. For instance, you might want to extend one distribution with one or two newer packages from Testing, Unstable or Experimental. It is possible to assign a priority to each available package (the same package can have several priorities depending on its version or the distribution providing it). These priorities will influence APT's behavior: for each package, it will always select the version with the highest priority (except if this version is older than the installed one and if its priority is less than 1000).

apt_preferences

preferences

APT

pinning

APT

preferences

APT

APT::Default-Release

APT

/etc/apt/preferences

APT

/etc/apt/preferences.d/

apt

-t

release

apt-get

-t

release

APT defines several default priorities. Each installed package version has a priority of 100. A non-installed version has a priority of 500 by default, but it can jump to 990 if it is part of the target release (defined with the -t command-line option or the APT::Default-Release configuration directive).

You can modify the priorities by adding entries in a file in /etc/apt/preferences.d/ or the /etc/apt/preferences file with the names of the affected packages, their version, their origin and their new priority.

APT will never install an older version of a package (that is, a package whose version number is lower than the one of the currently installed package) except if its priority is higher than 1000 (or it is explicitly requested by the user, see Installing and Removing). APT will always install the highest priority package which follows this constraint. If two packages have the same priority, APT installs the newest one (whose version number is the highest). If two packages of same version have the same priority but differ in their content, APT installs the version that is not installed (this rule has been created to cover the case of a package update without the increment of the revision number, which is usually required).

In more concrete terms, a package whose priority is

APT

package priority

< 0
will never be installed,

1..99
will only be installed if no other version of the package is already installed,

100..499
will only be installed if there is no other newer version installed or available in another distribution,

500....989
will only be installed if there is no newer version installed or available in the target distribution,

990..1000
will be installed except if the installed version is newer,

> 1000
will always be installed, even if it forces APT to downgrade to an older version.

When APT checks /etc/apt/preferences and /etc/apt/preferences.d/, it first takes into account the most specific entries (often those specifying the concerned package), then the more generic ones (including, for example, all the packages of a distribution). If several generic entries exist, the first match is used. The available selection criteria include the package's name and the source providing it. Every package source is identified by the information contained in a Release file that APT downloads together with the Packages files. It specifies the origin (usually “Debian” for the packages of official mirrors, but it can also be a person's or an organization's name for third-party repositories). It also gives the name of the distribution (usually Stable, Testing, Unstable or Experimental for the standard distributions provided by Debian) together with its version (for example, 12 for Debian Bookworm). Let's have a look at its syntax through some realistic case studies of this mechanism.

Package: *
Pin: release a=experimental
Pin-Priority: 500

Let's suppose that you only want to use packages from the stable version of Debian. Those provided in other versions should not be installed except if explicitly requested. You could write the following entries in the /etc/apt/preferences file:

Package: *
Pin: release a=stable
Pin-Priority: 900

Package: *
Pin: release o=Debian
Pin-Priority: -10

a=stable defines the name of the selected distribution. o=Debian limits the scope to packages whose origin is “Debian”.

Package: *
Pin: release n=bookworm-updates
Pin-Priority: 990

Package: *
Pin: release n=bookworm-security
Pin-Priority: 990

Package: *
Pin: release n=bookworm
Pin-Priority: 990

Let's now assume that you have a server with several local programs depending on the version 5.32 of Perl and that you want to ensure that upgrades will not install another version of it. You could use this entry:

Package: perl
Pin: version 5.32*
Pin-Priority: 1001

apt-cache

policy

To gain a better understanding of the mechanisms of priority and distribution or repository properties to pin do not hesitate to execute apt-cache policy to display the default priority associated with each package source, or apt-cache policy package to display the default priority for each available version and source of a package as explained in The Command.

The reference documentation for the files /etc/apt/preferences and /etc/apt/preferences.d/ is available in the manual page apt_preferences(5), which you can display with man apt_preferences.

Explanation: The package xserver-xorg-video-intel provided
Explanation: in experimental can be used safely
Package: xserver-xorg-video-intel
Pin: release a=experimental
Pin-Priority: 500

Working with Several Distributions

apt being such a marvelous tool, it is tempting to pick packages coming from other distributions. For example, after having installed a Stable system, you might want to try out a software package available in Testing or Unstable without diverging too much from the system's initial state.

Even if you will occasionally encounter problems while mixing packages from different distributions, apt manages such coexistence very well and limits risks very effectively. The best way to proceed is to list all distributions used in /etc/apt/sources.list (some people always put the three distributions, but remember that Unstable is reserved for experienced users) and to define your reference distribution with the APT::Default-Release parameter (see System Upgrade).

Let's suppose that Stable is your reference distribution but that Testing and Unstable are also listed in your sources.list file. In this case, you can use apt install package/testing to install a package from Testing. If the installation fails due to some unsatisfiable dependencies, let it solve those dependencies within Testing by adding the -t testing parameter. The same obviously applies to Unstable.

In this situation, upgrades (upgrade and full-upgrade) are done within Stable except for packages already upgraded to another distribution: those will follow updates available in the other distributions. We will explain this behavior with the help of the default priorities set by APT below. Do not hesitate to use apt-cache policy (see The Command) to verify the given priorities.

Everything centers around the fact that APT only considers packages of higher or equal version than the installed one (assuming that /etc/apt/preferences has not been used to force priorities higher than 1000 for some packages).

Let's assume that you have installed version 1 of a first package from Stable and that version 2 and 3 are available respectively in Testing and Unstable. The installed version has a priority of 100 but the version available in Stable (the very same) has a priority of 990 (because it is part of the target release). Packages in Testing and Unstable have a priority of 500 (the default priority of a non-installed version). The winner is thus version 1 with a priority of 990. The package “stays in Stable”.

Let's take the example of another package whose version 2 has been installed from Testing. Version 1 is available in Stable and version 3 in Unstable. Version 1 (of priority 990 — thus lower than 1000) is discarded because it is lower than the installed version. This only leaves version 2 and 3, both of priority 500. Faced with this alternative, APT selects the newest version, the one from Unstable. If you don't want a package installed from Testing to migrate to the version in Unstable, you have to assign a priority lower than 500 (490 for example) to packages coming from Unstable. You can modify /etc/apt/preferences to this effect:

Package: *
Pin: release a=unstable
Pin-Priority: 490

Tracking Automatically Installed Packages

One of the essential functionalities of apt is the tracking of packages installed only through dependencies. These packages are called “automatic”, and often include libraries.

apt

autoremove

apt-get

autoremove

APT

automatic removal

package

automatic removal

With this information, when packages are removed, the package managers can compute a list of automatic packages that are no longer needed (because there is no “manually installed” packages depending on them). apt-get autoremove or apt autoremove will get rid of those packages. aptitude does not have this command because it removes them automatically as soon as they are identified. In all cases, the tools display a clear message listing the affected packages.

package

automatic

package

manual

package

markauto

package

unmarkauto

apt-mark

auto

apt-mark

manual

aptitude

markauto

aptitude

unmarkauto

It is a good habit to mark as automatic any package that you don't need directly so that they are automatically removed when they aren't necessary anymore. apt-mark auto package will mark the given package as automatic whereas apt-mark manual package does the opposite. aptitude markauto and aptitude unmarkauto work in the same way although they offer more features for marking many packages at once (see ). The console-based interactive interface of aptitude also makes it easy to review the “automatic flag” on many packages.

aptitude

why

People might want to know why an automatically installed package is present on the system. To get this information from the command line, you can use aptitude why package (apt and apt-get have no similar feature):

$ aptitude why python3-debian
i   python3-reportbug Depends python3-debian

APT Patterns

APT

patterns

apt-patterns

apt

list

Patterns allow you to specify complex search queries to select the packages you want to install or show. They were first implemented for aptitude (see Frontends: , ), but now APT can also make use of them.

For example, we can use apt list ?automatic to list all the packages automatically installed. To find packages automatically installed no longer depended upon by manually installed packages the pattern ?garbage can be used.

Logic patterns can be combined with other packages to form more complex expressions. For instance, we could use a pattern like ?and(PATTERN, PATTERN). See apt-patterns(7) and glob(7) for all the patterns you can use and the complex expressions you can create with them.

The apt-cache Command

apt-cache

APT

package search

APT

header display

APT

cache

search of packages

package

search

The apt-cache command can display much of the information stored in APT's internal database. This information is a sort of cache since it is gathered from the different sources listed in the sources.list file. This happens during the apt update operation.

apt

search

apt

show

apt-cache

search

apt-cache

show

aptitude

search

aptitude

show

The apt-cache command can do keyword-based package searches with apt-cache search keyword. It can also display the headers of the package's available versions with apt-cache show package. This command provides the package's description, its dependencies, the name of its maintainer, etc. Note that apt search, apt show, aptitude search, and aptitude show work in the same way.

$ axi-cache search package use::searching
axi-cache search package use::searching
30 results found.
Results 1-20:
100% packagesearch - GUI for searching packages and viewing package information
94% mlocate - transitional dummy package
87% cruft - transitional package
86% debtags - Debian Package Tags support tools
85% whohas - query multiple distributions' package archives
84% recoll - Personal full text search package
81% apt-forktracer - utility for tracking non-official package versions
[..]
68% wajig - unified package management front-end for Debian/Ubuntu
More terms: debian dctrl packagesearch information aptitude manager dpkg
More tags: admin::package-management works-with::software:package role::program suite::debian interface::commandline scope::application scope::utility
`axi-cache more' will give more results

apt-cache

dumpavail

apt-cache

pkgnames

Some features are more rarely used. For instance, apt-cache dumpavail displays the headers of all available versions of all packages. apt-cache pkgnames displays the list of all the packages which appear at least once in the cache.

One of the features which might come in handy more often is apt-cache policy, described in the following section.

The apt-cache policy Command

apt-cache

policy

APT

pinning

priorities

The apt-cache policy command displays the pinning priorities and distribution properties of each package source as explained in Managing Package Priorities. It can also show the pinning priorities for all available versions and sources of a package. For the sources.list example used in example_title and APT::Default-Release set to "/^bookworm(|-security|-updates)$/", the output will look like this:

$ apt-cache policy
Package files:
 100 /var/lib/dpkg/status
     release a=now
 990 http://deb.debian.org/debian bookworm-updates/non-free-firmware amd64 Packages
     release v=12-updates,o=Debian,a=stable-updates,n=bookworm-updates,l=Debian,c=non-free-firmware,b=amd64
     origin deb.debian.org
 990 http://deb.debian.org/debian bookworm-updates/main amd64 Packages
     release v=12-updates,o=Debian,a=stable-updates,n=bookworm-updates,l=Debian,c=main,b=amd64
     origin deb.debian.org
 990 http://security.debian.org/debian-security bookworm-security/non-free-firmware amd64 Packages
     release v=12,o=Debian,a=stable-security,n=bookworm-security,l=Debian-Security,c=non-free-firmware,b=amd64
     origin security.debian.org
 990 http://security.debian.org/debian-security bookworm-security/main amd64 Packages
     release v=12,o=Debian,a=stable-security,n=bookworm-security,l=Debian-Security,c=main,b=amd64
     origin security.debian.org
 990 http://deb.debian.org/debian bookworm/non-free-firmware amd64 Packages
     release v=12.5,o=Debian,a=stable,n=bookworm,l=Debian,c=non-free-firmware,b=amd64
     origin deb.debian.org
 990 http://deb.debian.org/debian bookworm/main amd64 Packages
     release v=12.5,o=Debian,a=stable,n=bookworm,l=Debian,c=main,b=amd64
     origin deb.debian.org
Pinned packages:

apt-cache policy can also show the pinning priorities for all available versions and sources of a given package.

$ apt-cache policy adb
adb:
  Installed: 1:29.0.6-28
  Candidate: 1:29.0.6-28
  Version table:
     1:33.0.3-2~bpo12+1 100
        100 http://deb.debian.org/debian bookworm-backports/main amd64 Packages
 *** 1:29.0.6-28 990
        990 http://deb.debian.org/debian bookworm/main amd64 Packages
        100 /var/lib/dpkg/status

APT

/etc/apt/preferences.d/

preferences

Although there is a newer version of adb in the bookworm-backports repository, APT will not install it automatically based on the priority. One would have to use apt install adb/bookworm-backports or add a higher pinning priority to /etc/apt/preferences.d/adb.pref:

Package: adb
Pin: release o=Debian Backports,n=bookworm-backports
Pin-Priority: 1001

$ apt-cache policy limnoria
adb:
  Installed: 1:29.0.6-28
  Candidate: 1:33.0.3-2~bpo12+1
  Version table:
     1:33.0.3-2~bpo12+1 1001
        100 http://deb.debian.org/debian bookworm-backports/main amd64 Packages
 *** 1:29.0.6-28 990
        990 http://deb.debian.org/debian bookworm/main amd64 Packages
        100 /var/lib/dpkg/status

The apt-file Command

apt-file

APT

file search

search of files

package

search files

Sometimes we refer to a file or a command and you might wonder, in which package it will be found. Fortunately the Debian repositories not only contain information about all the binary packages provided, but also all the files shipped with them. This information is stored in files named Contents-arch.gz and Contents-udeb-arch.gz. This information is not automatically downloaded by APT after installation. Instead it needs the apt-file update command (from the similar named package) to initially retrieve the contents of all package sources mentioned in /etc/apt/sources.list. By default it downloads Contents*.pdiff files as described in sidebar sidebar_title to reduce the amount of data necessary to be downloaded. To update the database on a weekly base, the following entry can be added to /etc/crontab if convenient. After installing apt-file, every apt-get update will also retrieve and update the Contents files.

@weekly root test -x /usr/bin/apt-file && /usr/bin/apt-file update >> /dev/null 2>&1

apt-file

search

After the database has been updated, the command apt-file search pattern will list all packages, which contain a filename or path containing the pattern.

$ apt-file search bin/axi-cache
apt-xapian-index: /usr/bin/axi-cache

apt-file

list

The command apt-file list package will list all files shipped with the package instead.

Frontends: aptitude, synaptic

aptitude

synaptic

APT

interfaces

APT is a C++ program whose code mainly resides in the libapt-pkg shared library. Using a shared library facilitates the creation of user interfaces (frontends), since the code contained in the library can easily be reused. Historically, apt-get was only designed as a test frontend for libapt-pkg but its success tends to obscure this fact.

aptitude

aptitude

APT

interfaces

aptitude

aptitude

aptitude is an interactive program that can be used in semi-graphical mode on the console. You can browse the list of installed and available packages, look up all the available information, and select packages to install or remove. The program is designed specifically to be used by administrators, so that its default behaviors are designed to be much more intelligent than apt-get's, and its interface much easier to understand.

aptitude

basic usage

When it starts, aptitude shows a list of packages sorted by state (installed, non-installed, or installed but not available on the mirrors — other sections display tasks, virtual packages, and new packages that appeared recently on mirrors). To facilitate thematic browsing, other views are available. In all cases, aptitude displays a list combining categories and packages on the screen. Categories are organized through a tree structure, whose branches can respectively be unfolded or closed with the Enter, [ and ] keys. + should be used to mark a package for installation, - to mark it for removal and _ to purge it (note that these keys can also be used for categories, in which case the corresponding actions will be applied to all the packages of the category). u updates the lists of available packages and Shift+u prepares a global system upgrade. g switches to a summary view of the requested changes (and typing g again will apply the changes), and q quits the current view. If you are in the initial view, this will effectively close aptitude.

aptitude

package search

To search for a package, you can type / followed by a search pattern. This pattern matches the name of the package, but can also be applied to the description (if preceded by ~d), to the section (with ~s) or to other characteristics detailed in the documentation. The same patterns can filter the list of displayed packages: type the l key (as in limit) and enter the pattern.

aptitude

automatic flag

aptitude

markauto

Managing the “automatic flag” of Debian packages (see Tracking Automatically Installed Packages) is a breeze with aptitude. It is possible to browse the list of installed packages and mark packages as automatic with Shift+m or to remove the mark with the m key. “Automatic packages” are displayed with an “A” in the list of packages. This feature also offers a simple way to visualize the packages in use on a machine, without all the libraries and dependencies that you don't really care about. The related pattern that can be used with l (to activate the filter mode) is ~i!~M. It specifies that you only want to see installed packages (~i) not marked as automatic (!~M).

# aptitude markauto '~slibs|~sperl'

Managing Recommendations, Suggestions and Tasks

aptitude

tasks

Another interesting feature of aptitude is the fact that it respects recommendations between packages while still giving users the choice not to install them on a case by case basis. For example, the gnome package recommends transmission-gtk (among others). When you select the former for installation, the latter will also be selected (and marked as automatic if not already installed on the system). Typing g will make it obvious: transmission-gtk appears on the summary screen of pending actions in the list of packages installed automatically to satisfy dependencies. However, you can decide not to install it by deselecting it before confirming the operations.

Note that this recommendation tracking feature does not apply to upgrades. For instance, if a new version of gnome recommends a package that it did not recommend formerly, the package won't be marked for installation. However, it will be listed on the upgrade screen so that the administrator can still select it for installation.

Suggestions between packages are also taken into account, but in a manner adapted to their specific status. For example, since gnome suggests empathy, the latter will be displayed on the summary screen of pending actions (in the section of packages suggested by other packages). This way, it is visible and the administrator can decide whether to take the suggestion into account or not. Since it is only a suggestion and not a dependency or a recommendation, the package will not be selected automatically — its selection requires a manual intervention from the user (thus, the package will not be marked as automatic).

In the same spirit, remember that aptitude makes intelligent use of the concept of task. Since tasks are displayed as categories in the screens of packages lists, you can either select a full task for installation or removal, or browse the list of packages included in the task to select a smaller subset.

Better Solver Algorithms

aptitude

solver

To conclude this section, let's note that aptitude has more elaborate algorithms compared to apt-get when it comes to resolving difficult situations. When a set of actions is requested and when these combined actions would lead to an incoherent system, aptitude evaluates several possible scenarios and presents them in order of decreasing relevance. However, these algorithms are not fail-proof. Fortunately there is always the possibility to manually select the actions to perform. When the currently selected actions lead to contradictions, the upper part of the screen indicates a number of “broken” packages (and you can directly navigate to those packages by pressing b). It is then possible to manually build a solution for the problems found. In particular, you can get access to the different available versions by simply selecting the package with Enter. If the selection of one of these versions solves the problem, you should not hesitate to use the function. When the number of broken packages gets down to zero, you can safely go to the summary screen of pending actions for a last check before you apply them.

synaptic

synaptic

APT

interfaces

synaptic

synaptic

synaptic is a graphical package manager for Debian which features a clean and efficient graphical interface based on GTK+/GNOME. Its many ready-to-use filters give fast access to newly available packages, installed packages, upgradable packages, obsolete packages and so on. If you browse through these lists, you can select the operations to be done on the packages (install, upgrade, remove, purge); these operations are not performed immediately, but put into a task list. A single click on a button then validates the operations, and they are performed in one go.

Checking Package Authenticity

package

authenticity check

package

seal

package

signature

signature

package signature

authentication

package authentication

Release

Release.gpg

InRelease

APT

apt-secure

APT

archive authentification

Security is very important for Falcot Corp administrators. Accordingly, they need to ensure that they only install packages which are guaranteed to come from Debian with no tampering on the way. A computer cracker could try to add malicious code to an otherwise legitimate package. Such a package, if installed, could do anything the cracker designed it to do, including for instance disclosing passwords or confidential information. To circumvent this risk, Debian provides a tamper-proof seal to guarantee — at install time — that a package really comes from its official maintainer and hasn't been modified by a third party.

The seal works with a chain of cryptographic hashes and a signature and is explained in detail in apt-secure(8). Starting with Debian 10 Buster the signed file is the InRelease file, provided by the Debian mirrors. There is also a legacy file called Release. Both contain a list of the Packages files (including their compressed forms, Packages.gz and Packages.xz, and the incremental versions), along with their SHA256 hashes, which ensures that the files haven't been tampered with. These Packages files contain a list of the Debian packages available on the mirror, along with their hashes, which ensures in turn that the contents of the packages themselves haven't been altered either. The difference between InRelease and Release is that the former is cryptographically signed in-line, whereas the latter provides a detached signature in the form of the file Release.gpg.

signature

repository signature

APT

/etc/apt/trusted.gpg

apt-key

APT

/etc/apt/trusted.gpg.d/

apt-key

APT

Release

APT

Release.gpg

APT

InRelease

apt-key

APT needs a set of trusted GnuPG public keys to verify signatures in the InRelease and Release.gpg files available on the mirrors. It gets them from files in /etc/apt/trusted.gpg.d/ and from the /etc/apt/trusted.gpg keyring (managed by the apt-key command). The official Debian keys are provided and kept up-to-date by the debian-archive-keyring package which puts them in /etc/apt/trusted.gpg.d/:

# ls /etc/apt/trusted.gpg.d/
debian-archive-bookworm-automatic.asc
debian-archive-bookworm-security-automatic.asc
debian-archive-bookworm-stable.asc
debian-archive-bullseye-automatic.asc
debian-archive-bullseye-security-automatic.asc
debian-archive-bullseye-stable.asc
debian-archive-buster-automatic.asc
debian-archive-buster-security-automatic.asc
debian-archive-buster-stable.asc

$ sudo wget -O falcot-keyring.gpg -P /usr/share/keyrings https://packages.falcot.com/debian/repository.gpg

deb [ signed-by=/usr/share/keyrings/falcot-keyring.gpg ] https://packages.falcot.com/debian bullseye main

Once the appropriate keys are in the keyring, APT will check the signatures before any risky operation, so that frontends will display a warning if asked to install a package whose authenticity can't be ascertained.

Note, that binary packages are usually not signed. The integrity of a package can only be confirmed by checking its hashsums against a trusted (and possibly signed) hashsum source.

deb [ trusted=yes ] http://packages.falcot.com/ updates/
deb [ trusted=yes ] http://packages.falcot.com/ internal/

Upgrading from One Stable Distribution to the Next

system

dist-upgrade

dist-upgrade

APT

dist-upgrade

One of the best-known features of Debian is its ability to upgrade an installed system from one stable release to the next: dist-upgrade — a well-known phrase — has largely contributed to the project's reputation. With a few precautions, upgrading a computer can take as little as a few minutes, or a few dozen minutes, depending on the download speed from the package repositories.

Recommended Procedure

system

release notes

Since Debian has quite some time to evolve in-between stable releases, you should read the release notes before upgrading.

In this section, we will focus on upgrading a Bullseye system to Bookworm. This is a major operation on a system; as such, it is never 100% risk-free, and should not be attempted before all important data has been backed up.

aptitude

deborphan

debfoster

apt-show-versions

Another good habit which makes the upgrade easier (and shorter) is to tidy your installed packages and keep only the ones that are really needed. Helpful tools to do that include aptitude, deborphan, debfoster, and apt-show-versions (see Tracking Automatically Installed Packages). For example, you can use the following command, and then use aptitude's interactive mode to double check and fine-tune the scheduled removals:

aptitude

--schedule-only

# deborphan | xargs aptitude --schedule-only remove

updates

system

APT

update package list

APT

system update

system

update

apt

update

apt-get

update

aptitude

update

synaptic

Now for the upgrading itself. First, you need to change the /etc/apt/sources.list file to tell APT to get its packages from Bookworm instead of Bullseye. If the file only contains references to Stable rather than explicit codenames, the change isn't even required, since Stable always refers to the latest released version of Debian. In both cases, the database of available packages must be refreshed with the apt update command or the refresh button in synaptic (see Initialization).

apt

upgrade

apt-get

upgrade

aptitude

safe-upgrade

system

upgrade

Once these new package sources are registered, you should first do a minimal upgrade with apt upgrade et al. as described in System Upgrade. By doing the upgrade in two steps, we ease the job of the package management tools and often ensure that we have the latest versions of those, which might have accumulated bugfixes and improvements required to complete the full distribution upgrade.

system

dist-upgrade

system

full-upgrade

Once this first upgrade is done, it is time to handle the upgrade itself, either with apt full-upgrade, aptitude, or synaptic (see Upgrading from One Stable Distribution to the Next). You should carefully check the suggested actions before applying them: you might want to add suggested packages or deselect packages which are only recommended and known not to be useful. In any case, the frontend should come up with a scenario ending in a coherent and up-to-date Bookworm system. Then, all you need is to do is wait while the required packages are downloaded, answer the debconf questions and possibly those about locally modified configuration files, and sit back while APT does its magic.

Handling Problems after an Upgrade

In spite of the Debian maintainers' best efforts, a major system upgrade isn't always as smooth as you could wish. New software versions may be incompatible with previous ones (for instance, their default behavior or their data format may have changed). Also, some bugs may slip through the cracks despite the testing phase which always precedes a Debian release.

To anticipate some of these problems, you can install the apt-listchanges package, which displays information about possible problems at the beginning of a package upgrade. This information is compiled by the package maintainers and put in /usr/share/doc/package/NEWS.Debian files for the benefit of users. Reading these files (possibly through apt-listchanges) should help you avoid bad surprises.

bugs.debian.org

reportbug

You might sometimes find that the new version of a software doesn't work at all. This generally happens if the application isn't particularly popular and hasn't been tested enough; a last-minute update can also introduce regressions which are only found after the stable release. In both cases, the first thing to do is to have a look at the bug tracking system at https://bugs.debian.org/package, and check whether the problem has already been reported. If this is case, it will be also listed before the upgrade begins if you have apt-listbugs installed. If it hasn't, you should report it yourself with reportbug. If it is already known, the bug report and the associated messages are usually an excellent source of information related to the bug:

• sometimes a patch already exists, and it is available on the bug report; you can then recompile a fixed version of the broken package locally (see ???);

• in other cases, users may have found a workaround for the problem and shared their insights about it in their replies to the report;

• in yet other cases, a fixed package may have already been prepared and made public by the maintainer.

Depending on the severity of the bug, a new version of the package may be prepared specifically for a new revision of the stable release. When this happens, the fixed package is made available in the proposed-updates section of the Debian mirrors (see Proposed Updates). The corresponding entry can then be temporarily added to the sources.list file, and updated packages can be installed with apt or aptitude.

release.debian.org

proposed updates

Sometimes the fixed package isn't available in this section yet because it is pending a validation by the Stable Release Managers. You can verify if that is the case on their web page. Packages listed there aren't available yet, but at least you know that the publication process is ongoing.

Cleaning Up after an Upgrade

upgrade

cleaning

system

cleaning

APT usually ensures a clean upgrade, pulling in new and updated dependencies, or removing conflicting packages. But even being such a great tool, it cannot cover all tasks users and administrators will face after an upgrade, because they require a human decision.

Packages removed from the Debian Archive

apt-show-versions

aptitude

obsolete packages

package

obsolete

Sometimes the Debian ftpmasters remove packages from the Debian archive, because they contain release critical bugs, were abandoned by their upstream author or their package maintainer, or simply reached their end of life. In this case, a newer Debian release does not ship the package anymore. To find all packages, which do not have a package source, use the apt-show-versions command:

$ apt-show-versions | grep "No available version"

A similar result can be achieved by aptitude search ~o. If the packages found are not required anymore, they should be purged from the system, because they will not face any updates for critical or security related bugs anymore.

Dummy and Transitional Packages

dummy package

transitional package

package

transitional

package

dummy

package

oldlibs

oldlibs

aptitude

deborphan

debfoster

Sometimes, it might be necessary for a package to get a new name. In this case often the old package is kept as an (almost) empty package, depending on the new one and installing only the mandatory files in /usr/share/doc/package/. Such packages are called "dummy" or "transitional" packages. If the package maintainer in charge also changed the section of this package to oldlibs, then tools like aptitude, deboprhan, or debfoster (see sidebar sidebar_title) can pickup these packages to suggest their removal.

Unfortunately there is currently no foolproof way of making sure that these packages are automatically removed or picked by the tools mentioned above. One way to check if the system still has some of these packages installed, is to look through the package descriptions of installed packages and then check the results. Be careful not to schedule the results for automatic removal, because this method can lead to false positives:

$ dpkg -l | grep ^ii | grep -i -E "(transition|dummy)"

package

automatic

package

markauto

package

unmarkauto

Because the new package is pulled in as a dependency of the transitional package, it is usually marked as automatically installed and might be scheduled for removal if you try to purge the transitional package from your system. In this case you can use either of the approaches described in sidebar sidebar_title and Tracking Automatically Installed Packages to selectively remove the transitional package.

Old or Unused Configuration Files

configuration

configuration files

.dpkg-dist

.dpkg-old

.ucf-old

.ucf-new

.ucf-dist

package

purge

apt

autoremove

apt-get

autoremove

If the upgrade was successful, there might be some configuration file cruft, either from dpkg (see ???), ucf or from removed packages. The latter can be purged by using apt autoremove --purge. The configuration files that were handled by dpkg or ucf during the upgrade process have left some counterparts with a dedicated suffix, e.g. .dpkg-dist, .dpkg-old, .ucf-old. Using the find or locate command can help to track them down. If they are no longer of any use, they can be deleted.

Be aware that a purge also removes the data created with a particular package (e.g. database files, docker volumes and containers, etc.). There should always be backups in place in case data gets removed accidentally.

Files not owned by any Package

The Debian policy enforces that packages don't leave files behind when they are purged. Violating this principle is a serious bug and you will rarely encounter it. If you do, report it; and if you are curious though, you can use the cruft or cruft-ng package to check your system for files not owned by any package.

Keeping a System Up to Date

system

update

unattended

system

upgrade

unattended

system

dist-upgrade

unattended

system

periodic update

system

unattended upgrade

The Debian distribution is dynamic and changes continually. Most of the changes are in the Testing and Unstable versions, but even Stable is updated from time to time, mostly for security-related fixes. Whatever version of Debian a system runs, it is generally a good idea to keep it up to date, so that you can get the benefit of recent evolution and bug fixes.

While it is of course possible to periodically run a tool to check for available updates and run the upgrades, such a repetitive task is tedious, especially when it needs to be performed on several machines. Fortunately, like many repetitive tasks, it can be partly automated, and a set of tools have already been developed to that effect.

The first of these tools is apticron, in the package of the same name. Its main effect is to run a script daily (via cron). The script updates the list of available packages, and, if some installed packages are not in the latest available version, it sends an email with a list of these packages along with the changes that have been made in the new versions. Obviously, this package mostly targets users of Debian Stable, since the daily emails would be very long for the faster paced versions of Debian. When updates are available, apticron automatically downloads them. It does not install them — the administrator will still do it — but having the packages already downloaded and available locally (in APT's cache) makes the job faster.

APT

/etc/cron.daily/apt-compat

APT

/etc/apt/apt.conf.d/10periodic

/etc

/etc/cron.daily/apt-compat

Administrators in charge of several computers will no doubt appreciate being informed of pending upgrades, but the upgrades themselves are still as tedious as they used to be. Periodic upgrades can be enabled: it uses a systemd timer unit or cron. If systemd is not installed, the /etc/cron.daily/apt-compat script (in the apt package) comes in handy. This script is run daily (and non-interactively) by cron. To control the behavior, use APT configuration variables (which are therefore stored in a file /etc/apt/apt.conf.d/10periodic). The main variables are:

APT::Periodic::Update-Package-Lists
This option allows you to specify the frequency (in days) at which the package lists are refreshed. apticron users can do without this variable, since apticron already does this task.

APT::Periodic::Download-Upgradeable-Packages
Again, this option indicates a frequency (in days), this time for the downloading of the actual packages. Again, apticron users won't need it.

APT::Periodic::AutocleanInterval
This option covers a feature that apticron doesn't have. It controls how often obsolete packages (those not referenced by any distribution anymore) are removed from the APT cache. This keeps the APT cache at a reasonable size and means that you don't need to worry about that task.

APT::Periodic::Unattended-Upgrade

APT

/etc/apt/apt.conf.d/50unattended-upgrades

When this option is enabled, the daily script will execute unattended-upgrade (from the unattended-upgrades package) which — as its name suggest — can automatize the upgrade process for some packages (by default it only takes care of security updates, but this can be customized in /etc/apt/apt.conf.d/50unattended-upgrades). Note that this option can be set with the help of debconf by running dpkg-reconfigure -plow unattended-upgrades. If apt-listbugs is installed, it will prevent an automatic upgrade of packages which are affected by an already reported serious or grave bug.

APT

/usr/lib/apt/apt.systemd.daily

Other options can allow you to control the cache cleaning behavior with more precision. They are not listed here, but they are described in the /usr/lib/apt/apt.systemd.daily script.

These tools work very well for servers, but desktop users generally prefer a more interactive system. The package gnome-software provides an icon in the notification area of desktop environments when updates are available; clicking on this icon then runs an interface to perform updates. You can browse through available updates, read the short description of the relevant packages and the corresponding changelog entries, and select whether to apply the update or not on a case-by-case basis.

This tool is no longer installed in the default GNOME desktop. The new philosophy is that security updates should be automatically installed, either in the background or, preferably, when you shutdown your computer so as to not confuse any running application.

Automatic Upgrades

upgrade

automatic system upgrade

upgrade

non-interactive

system

automatic upgrade

automatic upgrade

non-interactive upgrade

Since Falcot Corp has many computers but only limited manpower, its administrators try to make upgrades as automatic as possible. The programs in charge of these processes must therefore run with no human intervention.

Configuring dpkg

dpkg

--force-confdef

dpkg

--force-confold

As we have already mentioned (see sidebar ???), dpkg can be instructed not to ask for confirmation when replacing a configuration file (with the --force-confdef --force-confold options). Interactions can, however, have three other sources: some come from APT itself, some are handled by debconf, and some happen on the command line due to package configuration scripts (sometimes handled by ucf).

Configuring APT

apt

--assume-yes

apt-get

--assume-yes

aptitude

--assume-yes

The case of APT is simple: the -y option (or --assume-yes) tells APT to consider the answer to all its questions to be “yes”.

Configuring debconf

debconf

frontend

noninteractive

The case of debconf deserves more details. This program was, from its inception, designed to control the relevance and volume of questions displayed to the user, as well as the way they are shown. That is why its configuration requests a minimal priority for questions; only questions above the minimal priority are displayed. debconf assumes the default answer (defined by the package maintainer) for questions which it decided to skip.

The other relevant configuration element is the interface used by the frontend. If you choose noninteractive out of the choices, all user interaction is disabled. If a package tries to display an informative note, it will be sent to the administrator by email.

dpkg-reconfigure

APT

DEBIAN_FRONTEND

environment variable

DEBIAN_FRONTEND

To reconfigure debconf, use the dpkg-reconfigure tool from the debconf package; the relevant command is dpkg-reconfigure debconf. Note that the configured values can be temporarily overridden with environment variables when needed (for instance, DEBIAN_FRONTEND controls the interface, as documented in the debconf(7) manual page).

Handling Command Line Interactions

The last source of interactions, and the hardest to get rid of, is the configuration scripts run by dpkg. There is unfortunately no standard solution, and no answer is overwhelmingly better than another.

The common approach is to suppress the standard input by redirecting the empty content of /dev/null into it with command </dev/null, or to feed it with an endless stream of newlines. None of these methods is 100 % reliable, but they generally lead to the default answers being used, since most scripts consider a lack of reply as an acceptance of the default value.

The Miracle Combination

By combining the previous elements, it is possible to design a small but rather reliable script which can handle automatic upgrades.

export DEBIAN_FRONTEND=noninteractive
yes '' | apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade

Searching for Packages

package

search package

With the large and ever-growing amount of software in Debian, there emerges a paradox: Debian usually has a tool for most tasks, but that tool can be very difficult to find among the myriad other packages. The lack of appropriate ways to search for (and to find) the right tool has long been a problem. Fortunately, this problem has almost entirely been solved.

The most trivial search possible is looking up an exact package name. If apt show package returns a result, then the package exists. Unfortunately, this requires knowing or even guessing the package name, which isn't always possible.

apt-cache

search

axi-cache

search

A slightly more successful searching pattern is a plain-text search in package names, but it remains very limited. You can generally find results by searching package descriptions: since each package has a more or less detailed description in addition to its package name, a keyword search in these descriptions will often be useful. apt-cache and axi-cache are the tools of choice for this kind of search (see sidebar_title); for instance, apt-cache search video will return a list of all packages whose name or description contains the keyword “video”.

aptitude

search

aptitude

show

For more complex searches, a more powerful tool such as aptitude is required. aptitude allows you to search according to a logical expression based on the package's meta-data fields. For instance, the following command searches for packages whose name contains iso, whose description contains cd and whose maintainer's name contains joerg:

$ aptitude search iso~dcd~mjoerg
p   genisoimage  - Creates ISO-9660 CD-ROM filesystem images
$ aptitude show evince
Package: genisoimage              
Version: 9:1.1.11-3.4
State: not installed
Priority: optional
Section: otherosfs
Maintainer: Joerg Jaspert <joerg@debian.org>
Architecture: amd64
Uncompressed Size: 1698 k
Depends: libbz2-1.0, libc6 (>= 2.33), libmagic1 (>= 5.12), zlib1g (>= 1:1.1.4)
Suggests: wodim, cdrkit-doc
Conflicts: mkhybrid, mkisofs
Replaces: mkisofs
Provides: mkisofs
Description: Creates ISO-9660 CD-ROM filesystem images
 genisoimage is a pre-mastering program for creating ISO-9660 CD-ROM filesystem
 images, which can then be written to CD or DVD media using the wodim program.
 genisoimage includes support for making bootable "El Torito" CDs, as well as
 CDs with support for the Macintosh HFS filesystem. 
 
 The package also includes extra tools useful for working with ISO images: 
 * mkzftree - create ISO-9660 image with compressed contents 
 * dirsplit - easily separate large directory contents into disks of predefined size 
 * geteltorito - extract an El Torito boot image from a CD image 
   
 Please install cdrkit-doc if you want most of the documentation and README files.
Tags: hardware::storage, hardware::storage:cd, hardware::storage:dvd,
      interface::commandline, role::program, scope::utility, use::storing,
      works-with-format::iso9660, works-with::archive

The search only returns one package, genisoimage, which satisfies all three criteria.

Even these multi-criteria searches are rather unwieldy, which explains why they are not used as much as they could. A new tagging system has therefore been developed, and it provides a new approach to searching. Packages are given tags that provide a thematic classification along several strands, known as a “facet-based classification”. In the case of genisoimage above, the package's tags indicate that it is a storage- and more precisely CD- and DVD-related command-line utility to work with ISO9660 file-systems.

debtags.debian.org

Browsing this classification can help you to search for a package which corresponds to known needs; even if it returns a (moderate) number of hits, the rest of the search can be done manually. To do that, you can use the ~G search pattern in aptitude, but it is probably easier to simply navigate the site where tags are managed or use the debtags command:

tag

package

tags

$ debtags search "works-with::video && use::editing"

Selecting the works-with::video and use::editing tags yields a handful of packages, including the shotcut and pitivi video editors. This system of classification is bound to be used more and more as time goes on, and package managers will gradually provide efficient search interfaces based on it.

To sum up, the best tool for the job depends on the complexity of the search that you wish to do:

• apt-cache only allows searching in package names and descriptions, which is very convenient when looking for a particular package that matches a few target keywords;

  apt-cache

• when the search criteria also include relationships between packages or other meta-data such as the name of the maintainer, synaptic will be more useful;

  synaptic

• when a tag-based search is needed, a good tool is packagesearch, a graphical interface dedicated to searching available packages along several criteria (including the names of the files that they contain). For usage on the command-line, axi-cache will fit the bill.

  packagesearch

  axi-cache

• finally, when the searches involve complex expressions with logic operations, the tool of choice will be aptitude's search pattern syntax, which is quite powerful despite being somewhat obscure; it works in both the command-line and the interactive modes.

  aptitude