12.4 Basic Package Interaction with apt

update vs upgrade vs full-upgrade

The three commands form a pipeline, and confusing them is the single most common APT exam error:

1. apt update — refreshes the local package indexes from your repositories. Installs nothing. (See section 12.2.)
2. apt upgrade — installs newer versions of packages already installed, and may pull in brand-new packages when a dependency requires it, but with a hard rule: it will never remove an installed package. If completing an upgrade would mean dropping something, apt upgrade holds it back and reports 'The following packages have been kept back'. (Note the front-end difference the exam likes: apt-get upgrade is stricter still — it refuses to install any package that was not already installed.)
3. apt full-upgrade (the apt command's name for apt-get dist-upgrade) — upgrades the system and is allowed to install new dependencies and remove conflicting or obsolete packages to complete the transaction. It shows you the full plan, including removals, before asking for confirmation.

Why full-upgrade is the default on Kali

On a fixed-release distribution, plain apt upgrade is often enough because dependencies barely move. Kali is rolling: libraries like Python, OpenSSL, and glibc transition continuously, and a new tool version frequently depends on a library that does not exist on your system yet, or conflicts with a package that must go. If you only ever run apt upgrade, kept-back packages pile up and the system drifts into a partially updated state. The Kali documentation's recommended routine is therefore:

sudo apt update && sudo apt full-upgrade -y

Read the removal list before confirming — full-upgrade is safe, not blind, and a plan that wants to remove hundreds of packages usually means a broken mirror or a mid-transition repository, in which case you wait a few hours rather than accept.

install, remove, purge, autoremove

• apt install nmap — resolves dependencies, downloads, and installs. apt install nmap --reinstall refreshes an existing install; apt install ./local.deb installs a local file with dependency resolution (unlike dpkg -i).
• apt remove nmap — uninstalls the package but leaves system-wide configuration files (under /etc) in place, so reinstalling later restores your settings. dpkg shows such packages in rc state.
• apt purge nmap (or apt remove --purge nmap) — also deletes those configuration files. Use purge when a corrupted config is the reason you are reinstalling.
• apt autoremove — removes orphaned dependencies: packages that were installed automatically to satisfy a Depends that no longer exists. Over months of rolling upgrades this reclaims significant disk. apt autoremove --purge cleans their config files too.

A nuance worth knowing: the distinction between remove and purge applies to system-wide configuration only. Configuration inside a user's home directory (dotfiles) is never touched by either command — removing Burp Suite does not delete ~/.java settings.

Discovery and Inventory Commands

Before and after installing, you need to query the package world. Split the toolbox into APT-side (knows about repositories) and dpkg-side (knows about the local system):

APT-side queries

• apt search metasploit — full-text search over package names and descriptions in the downloaded indexes
• apt show nmap — prints the control-file metadata: version, dependencies, installed size, homepage, description. Works whether or not the package is installed; apt show -a nmap shows all available versions
• apt list --installed — lists everything installed (warns about unstable CLI, so use dpkg in scripts)
• apt list --upgradable — run after apt update to preview what an upgrade would touch, without changing anything

dpkg-side queries

• dpkg -l — lists every package dpkg knows about with a three-character state code (desired action / current status / error flag; the error column is blank in healthy output). The classic pattern is:

dpkg -l | grep '^ii'
dpkg -l | grep nmap

The first character is the desired action (i = install), the second the current status (i = installed). You will also see rc — removed but config files remain — which is your reminder that remove is not purge.

• dpkg -L nmap — lists the files a package installed
• dpkg -S /usr/bin/nmap — reverse lookup: which package owns this file? Invaluable on an unfamiliar engagement machine when you find a binary and want to know what put it there
• dpkg -s nmap — status and metadata for an installed package, from /var/lib/dpkg/status

A worked upgrade session

A typical maintenance cycle on Kali looks like this:

sudo apt update
apt list --upgradable
sudo apt full-upgrade
sudo apt autoremove

Note which commands need root: anything that modifies the system (update writing to /var/lib/apt/lists, upgrade, install, remove) needs sudo; pure queries (search, show, list, dpkg -l/-L/-S) run fine as the unprivileged kali user. The exam also likes to test that apt full-upgrade and apt-get dist-upgrade are two names for the same behavior — if a question describes 'an upgrade that may remove obsolete packages and install new dependencies', both answers describe one operation.

Finally, remember the ecosystem boundary these commands share: everything above operates only on packages from repositories in your sources.list. A tool you installed from a git clone, a pip package, or a downloaded AppImage is invisible to apt and dpkg — another reason exam answers that propose 'apt remove' to clean up a manually compiled tool are wrong.

Safer experimentation: simulate, hold, download

Three more tools round out the operational kit. Append --simulate (short form -s) to any install, upgrade, or remove command to see the complete plan without changing a single byte — the ideal way to inspect what full-upgrade intends to remove before you commit. apt-mark hold packagename pins an installed package so upgrades skip it (apt-mark showhold lists held packages); this is the standard workaround when a regression forces you to freeze a mission-critical tool until a fix lands. And apt download packagename fetches the .deb into your current directory without installing it, which is handy for offline inspection with dpkg-deb --info and dpkg-deb --contents. All three operate inside the same signed-repository model as every other command in this chapter. Two more belong in the same kit. apt clean empties /var/cache/apt/archives/ of every downloaded .deb, while apt autoclean removes only the cached .debs that are no longer downloadable from the mirror — the safer routine on a rolling system that upgrades constantly. And when a transaction is interrupted and dpkg leaves packages unpacked but unconfigured, dpkg --configure -a re-runs the pending configuration step for all of them; it is the low-level counterpart to apt --fix-broken install (the apt-get -f install you will see in older output).