12.1 Introduction to APT

What a .deb Package Actually Is

Every piece of software on Kali Linux — from the kernel to the smallest command-line utility — is delivered as a Debian package, a file with the .deb extension. Because Kali is built on Debian, it inherits Debian's entire packaging system, and the KLCP exam expects you to understand that system at a mechanical level.

A .deb file is not a proprietary format; it is a standard ar archive containing exactly three members:

• debian-binary — a plain text file with a single line (the format version, normally 2.0)
• control.tar (compressed as control.tar.gz, .xz, or .zst) — the package's metadata and maintainer scripts
• data.tar — the actual files the package installs, laid out as they will appear in the filesystem

You can prove this yourself: run ar t somepackage.deb to list the members, or dpkg-deb --info somepackage.deb and dpkg-deb --contents somepackage.deb for friendlier views of the metadata and file list.

The control file and dependency metadata

Inside control.tar, the most important file is control. It holds the fields that drive the entire package management system:

• Package and Version — the unique name and version string (for example 1:9.3p1-2, where 1: is the optional epoch, 9.3p1 is the upstream version, and -2 is the Debian revision)
• Architecture — amd64, arm64, all, and so on
• Depends — a comma-separated list of packages that must be present for this one to work, optionally with version constraints such as libc6 (>= 2.36)
• Recommends, Suggests, Pre-Depends, Conflicts, Breaks, Provides — softer or inverse relationships the resolver also honors
• Maintainer and Description

The control.tar may also contain maintainer scripts — preinst, postinst, prerm, and postrm — which run before/after installation and removal. This is how a package can create a system user or restart a service automatically when installed.

Why Dependencies Matter

Debian splits software into small, interlocking packages rather than shipping monolithic bundles. When you install a tool like Metasploit, you are really installing a tree of hundreds of packages: Ruby runtimes, shared libraries, database clients. The Depends metadata is what makes this practical — a package manager reads those fields and computes the complete set of packages to download, in the correct order. Without that automation you would be hunting shared libraries by hand, which is exactly the problem APT was built to solve.

Version strings and epochs

Debian version strings deserve a second look because APT's entire upgrade logic rests on comparing them. A version like 1:9.4-2 breaks into an optional epoch (the leading 1:, used when upstream numbering resets or regresses), the upstream version, and the Debian revision after the hyphen. APT upgrades a package only when the candidate version sorts strictly newer than the installed one — which is why downgrades require explicit force options or pinning. To inspect every version APT knows about, run apt-cache policy packagename: it prints the installed version, the candidate version, and which repository each available version would come from.

How APT Resolves and Fetches Packages

APT (Advanced Package Tool) is the high-level package management system. It works from repositories — servers hosting pools of .deb files plus index files describing them. When you run apt install nmap, APT:

1. Consults its local package index (downloaded earlier by apt update into /var/lib/apt/lists/)
2. Reads nmap's Depends/Recommends and recursively walks the dependency graph
3. Computes a full transaction: which packages to download, install, upgrade, or remove
4. Downloads every required .deb over HTTP/HTTPS into /var/cache/apt/archives/
5. Verifies integrity and hands the packages, in order, to the low-level tool that performs the actual installation

Repositories are authenticated: each ships a Release file signed with GPG (GNU Privacy Guard), and the index files carry checksums for every package. This is why adding a third-party repository requires importing its GPG key — APT will refuse or loudly warn about unauthenticated packages.

dpkg vs APT: Low Level vs High Level

dpkg is the low-level tool. It unpacks a .deb file that is already on your disk, runs its maintainer scripts, and records it in the dpkg database (/var/lib/dpkg/status). Crucially, dpkg does not download anything and does not resolve dependencies — dpkg -i foo.deb on a package with missing dependencies fails or leaves the system in a half-configured state (which you then repair with apt --fix-broken install). APT sits on top: it handles the network, the resolution, and the ordering, then calls dpkg for each package. The exam loves this layering:

• dpkg -i installs a local .deb file only
• apt install ./foo.deb installs a local .deb and resolves its dependencies from the repositories
• Everything dpkg knows, APT knows, because APT uses the same underlying database

apt vs apt-get vs aptitude

Three front ends exist, and the exam expects you to distinguish them:

The apt command essentially merges the most-used apt-get and apt-cache features (apt install, apt search, apt show, apt update). One important caveat: apt's output format is explicitly not guaranteed stable across versions — it even prints 'WARNING: apt does not have a stable CLI interface' when piped — so scripts should call apt-get/apt-cache instead. aptitude's resolver sometimes proposes solutions apt declines (for example, holding a package back instead of removing it), which is the main reason some administrators still keep it around.