apt — High Level Package Manager in Debian Ecosystem

apt is what you’ll actually use for nearly every package operation day to day — it talks to repositories, resolves dependencies automatically, and calls dpkg internally to do the actual file installation once everything’s been figured out. This chapter covers it properly, along with the repository configuration and trust mechanism underneath it.

Refreshing The Metadata: apt update

sudo apt update

This is one of the most commonly misunderstood commands in the entire Debian ecosystem: apt update does not install or upgrade anything. It only refreshes apt’s local cache of what’s available in each configured repository — new package versions, newly added packages — matching exactly the “fetch metadata” step from the package-management overview earlier in this section. Skipping this before an install can mean apt working from a stale picture of what’s actually available.

Without apt update, you may have seen:

Error: Unable to locate package nginx

You just need to apt update the listing of package currenly not available in local cache so that apt install can install it.

Installing With Dependency Resolution

sudo apt install nginx

Unlike dpkg -i from the last chapter, this searches configured repositories, resolves every dependency nginx needs, downloads all of it, and installs the complete set in one operation — reporting exactly what it’s about to do before proceeding:

The following additional packages will be installed:
  libnginx-mod-http-image-filter nginx-common
0 upgraded, 3 newly installed, 0 to remove
Do you want to continue? [Y/n]

That confirmation step is worth actually reading rather than reflexively confirming — it’s telling you exactly what’s about to change on the system, dependencies included.

Removing And Purging

sudo apt remove nginx
sudo apt purge nginx

Same distinction as dpkg -r/-P from the last chapter — remove leaves configuration behind, purge removes it too — except now dependency-aware: apt understands the relationship between nginx and whatever it pulled in alongside it, which sets up the next command directly.

Cleaning Up Orphaned Dependencies: apt autoremove

When apt install nginx pulled in libnginx-mod-http-image-filter as a dependency, it recorded that package as automatically installed — installed only because something else needed it, not because you explicitly asked for it. Removing nginx itself doesn’t automatically remove those dependencies, since apt can’t be sure nothing else still needs them.

sudo apt autoremove

This finds every package still marked as automatically installed that nothing currently installed actually depends on anymore, and offers to remove them — genuinely the standard cleanup step after removing something substantial, since skipping it tends to leave a slow accumulation of unused dependency packages over time.

Upgrading: upgrade vs. full-upgrade

sudo apt upgrade

Upgrades every currently installed package to its latest available version — but with one deliberate restriction: it will not remove any currently installed package to satisfy a new dependency requirement, even if that would otherwise be the correct resolution. If an upgrade genuinely requires removing something, apt upgrade simply holds that specific package back rather than removing anything.

sudo apt full-upgrade

Removes that restriction — if satisfying an upgrade genuinely requires removing an existing package, full-upgrade will do it. This is more thorough but also higher-risk, and worth understanding the distinction before reaching for it out of habit; upgrade is the safer default for routine maintenance, full-upgrade for a more significant version jump (a major distribution release upgrade, for instance) where that behavior is actually expected and desired.

Searching And Inspecting Before Installing

apt search nginx

Searches package names and descriptions across the cached metadata — no need to know an exact package name in advance.

apt show nginx

Full details on a specific package — description, version, dependencies, size — before committing to installing it.

apt list --installed
apt list --upgradable

Exactly what they sound like — everything currently installed, or everything currently installed with a newer version available.

apt-cache: The Older Companion Tool

apt itself is a relatively modern, user-friendly frontend. apt-cache, older and still genuinely useful, offers one command worth knowing specifically:

apt-cache policy nginx

Shows every version of nginx available across all configured repositories, along with which one would actually be installed and why — genuinely useful the moment more than one repository might provide different versions of the same package, and you need to understand which one wins.

Repository Configuration: sources.list

cat /etc/apt/sources.list
ls /etc/apt/sources.list.d/

Following the same main-file-plus-.d-directory pattern seen elsewhere in this course, repository definitions live in /etc/apt/sources.list and as individual files under /etc/apt/sources.list.d/. A typical line:

deb http://archive.ubuntu.com/ubuntu noble main restricted

Broken down: deb (binary packages, as opposed to deb-src for source packages), the repository URL, the distribution codename (noble, in this example), and one or more components — categories like main and restricted, each with different licensing or support implications on Ubuntu specifically.

Trust: Signed Repositories

Recall from the package-management overview that repositories sign their metadata, and apt verifies that signature before trusting anything downloaded from them. Trusted signing keys live under /etc/apt/trusted.gpg.d/, and modern practice ties a specific key directly to a specific repository entry using a signed-by option, rather than trusting a key globally for every configured repository:

deb [signed-by=/usr/share/keyrings/example-archive-keyring.gpg] http://example.com/apt stable main

apt vs. apt-get: A Practical Note

You’ll frequently see apt-get install in older documentation and scripts, alongside apt install. apt is the newer, friendlier frontend — better default output, a progress bar, more sensible defaults — while apt-get (paired with apt-cache) is older but has a specific advantage worth knowing: apt-get’s command-line interface is considered stable across versions, while apt’s output and behavior are explicitly not guaranteed to stay identical release to release. For interactive use, apt is the better everyday choice; inside a script meant to keep working reliably across upgrades, apt-get is generally the safer, more conventional choice.

What’s Next

You now have full command of the Debian package ecosystem — low-level dpkg and high-level apt together. The next chapter puts both to direct use: building an actual .deb package from scratch, from a small C program through to a fully traceable install and clean removal.