APT

APT (Advanced Package Tool) is the high-level package management system of Debian, Ubuntu and their derivatives in Linux. It downloads packages from signed repositories, resolves dependencies and then hands the actual installation of .deb files to the low-level tool dpkg.

The name covers both a library, libapt-pkg, and a family of front ends: the interactive apt command, the script-oriented apt-get and apt-cache, and graphical tools built on the same library. Since its introduction in Debian in 1998, APT has become the standard way to install, upgrade and remove software on Debian-based systems.

How APT works on top of dpkg

APT splits package management into two layers. dpkg knows how to unpack a single .deb file, run its maintainer scripts and record it in the package database, but it does not fetch anything or resolve dependencies. APT adds the missing layer: it knows which repositories exist, which versions they offer and which combination of packages satisfies every dependency.

A typical operation runs in a fixed order: APT reads the local package indexes, computes a solution, downloads the required archives, verifies their checksums and then calls dpkg to unpack and configure them. The table below lists the main components and where they live.

Because APT works from local copies of metadata, apt update must refresh them before APT can see new versions. Installing without a recent update is a common cause of 404 errors, since the mirror has already replaced the old file names.

Core APT commands and their effect

The most important distinction among APT commands is whether an operation may remove packages. A regular upgrade never removes installed packages, while a full upgrade may remove them to resolve changed dependencies, which is why it is used for release upgrades.

The apt front end is meant for people: it shows a progress bar, colors and a condensed summary, and its output format is not guaranteed stable. Scripts and configuration management tools should use apt-get and apt-cache, whose interfaces are kept backward compatible.

APT also tracks why each package is installed. Packages pulled in as dependencies are marked automatic, and apt autoremove deletes them once nothing depends on them; apt-mark manual protects a package from that cleanup.

Repositories, signatures and trust

Every APT repository is authenticated through a signed Release file. The InRelease file carries an OpenPGP signature and the SHA-256 hashes of every index file, and each index lists the hash of every package, so a single trusted key protects the whole chain down to individual .deb archives.

Modern systems describe repositories in the deb822 format in .sources files, which Debian 13 and Ubuntu 24.04 use by default. The current best practice binds each repository to its own key through the Signed-By field, replacing the deprecated global apt-key keyring that let any trusted key sign any repository.

Plain HTTP mirrors are acceptable precisely because of this design: integrity comes from signatures, not from the transport. HTTPS still adds confidentiality about which packages a host downloads.

Pinning and version priorities

When several sources offer the same package, APT chooses the candidate version by priority, not simply by the highest version number. Each source receives a default priority, and pinning rules in /etc/apt/preferences.d/ can override it per package or per release.

This mechanism explains why Backports packages are not installed automatically: their archive is marked with a priority of 100, so a user must request them with apt install -t trixie-backports pkg. Running apt-cache policy is the quickest way to see which version APT will choose and why.

APT compared with other package managers

APT belongs to the same class as DNF and Pacman: high-level managers that resolve dependencies and fetch from repositories. dpkg and RPM are the corresponding low-level tools that only handle local package files.

Common APT mistakes

• Mixing releases by adding testing or another distribution’s repository without pinning, which produces a fragile system often called a FrankenDebian.
• Running dpkg -i on a downloaded file and leaving unresolved dependencies; apt install ./file.deb resolves them instead.
• Interrupting an upgrade, which leaves packages half-configured until dpkg –configure -a finishes the job.
• Using apt in scripts, where its unstable output and interactive prompts cause failures; use apt-get -y instead.
• Adding third-party keys to the global trust store instead of binding them with Signed-By.

In simple terms

APT works like an app store for a Linux computer, operated by typed commands. It keeps a catalog of available software, checks that every download really comes from the trusted publisher and installs everything a program needs to run.

If a photo editor needs three extra libraries, APT notices that, fetches all four pieces and sets them up in the right order. Later, a single update command brings every installed program up to date at once.

A practical example

An administrator maintains 40 Ubuntu 24.04 web servers. Each night, an automation job runs apt-get update followed by apt-get -y upgrade, so security fixes arrive within a day without any package being removed unexpectedly.

A new application needs a newer PostgreSQL client than the distribution ships. The administrator adds the vendor repository as a deb822 file with Signed-By pointing to its own key, and adds a pin of 600 limited to the client packages. apt-cache policy confirms that only those packages come from the vendor while everything else stays on Ubuntu. The upgrade rolls out across all 40 servers with no dependency conflicts and no unplanned changes to other packages.