Linux Package Overview

Installing software without a package manager means manually downloading source code, compiling it, figuring out where every resulting file should go, and hoping you remember all of that later if you ever need to remove it cleanly. Every Linux package manager exists to replace that entirely — not just as a convenience, but as a genuine record-keeping system: what’s installed, exactly which files belong to it, and what it depends on. This chapter covers that model before touching any specific tool.

What A Package Actually Is?

A package is an archive — bundling three things together: the actual files to be installed (binaries, configuration, documentation), metadata describing the package itself (name, version, a human-readable description, and its dependencies), and, often, scripts to run at specific points during installation or removal. A .deb file and an .rpm file are both, at their core, exactly this — just packaged in different archive formats, with different conventions for the metadata inside them.

The Package Database: What Makes Clean Removal Possible

This is the single most important idea in this entire section, worth understanding before anything else: every package manager maintains a local database recording exactly what’s currently installed and — critically — exactly which files belong to which package. Installing a package isn’t just “copy some files onto disk” — it’s “copy these files, and record that they belong to this package,” which is precisely what makes it possible to later ask “what files did this package put on my system” and get a complete, reliable answer, or to remove a package and have every one of its files actually go with it.

Without this database, uninstalling anything cleanly would mean guessing — hunting through the filesystem trying to remember what a piece of software touched, with no authoritative source of truth. Hands-on chapters later in this section lean on this database constantly, listing exactly what a package installed and confirming exactly what’s left after removing it.

Repositories: Where Packages Actually Come From

A repository is a remote collection of packages, along with an index describing what’s available — names, versions, dependencies — separate from the actual package files themselves. When you ask to install something, the package manager doesn’t necessarily already have the software; it typically already has the metadata about what’s available (fetched and cached ahead of time), and downloads the actual package archive only once you request it.

Dependency Resolution

Most software depends on other software already being present — a program written against a particular library, for instance, won’t run without that library installed. Packages declare these dependencies explicitly in their metadata, and a package manager’s job includes resolving them: figuring out the complete set of additional packages needed to satisfy everything a requested package depends on, then installing all of it together as one coherent operation, not just the one package you explicitly asked for.

Maintainer Scripts: Installation Isn’t Just Copying Files

Beyond copying files, a package can bundle scripts that run automatically at specific points — before installation begins, immediately after files are copied, before removal starts, immediately after removal finishes. This is how a package can do things a plain file copy never could: creating a dedicated system user account for a service (exactly the pattern covered in the Users & Groups section earlier in this course), enabling a systemd unit automatically, or migrating an old configuration file format to a new one during an upgrade. A later chapter in this section covers this lifecycle in full detail — for now, just know that “installing a package” can genuinely mean more than files appearing on disk.

Trust: Why Signatures Matter

A package manager is, by design, capable of running scripts as root and placing files anywhere on the system. That’s a meaningful amount of trust to extend to something downloaded over a network, which is exactly why repositories cryptographically sign their package metadata — the package manager verifies that signature before trusting anything it downloads, refusing to proceed if the signature doesn’t check out. This is covered properly, hands-on, in a later chapter — worth flagging now as a foundational reason repository trust isn’t just a formality.

The Full Sequence, Visually

    flowchart TB
    A["Repository"] --> B["Fetch metadata:<br/>what's available, dependencies"]
    B --> C["Resolve dependencies"]
    C --> D["Download package archive(s)"]
    D --> E["Verify signature"]
    E --> F["Unpack files onto disk"]
    F --> G["Run maintainer scripts"]
    G --> H["Register in local<br/>package database"]
  

Every install you’ll do throughout this section, on either distro family, follows this same underlying shape — only the specific tools and file formats differ.

The Two-Tool Pattern

Both major package management ecosystems split responsibility across two tools, following the same underlying division: a low-level tool that operates on a single, already-present package file with no awareness of remote repositories or dependency resolution, and a high-level tool that talks to repositories, resolves dependencies, and internally calls the low-level tool to actually do the work.

Understanding both matters for different reasons: the high-level tool is what you’ll use for nearly everything day to day, while the low-level tool is what you’ll reach for when you need precise, direct answers — exactly which files a specific package owns, or installing a single package file you’ve built or downloaded yourself, outside of any repository.

What’s Next

With the underlying model in place — packages, databases, repositories, dependency resolution, and trust — the next chapter gets hands-on with the first of these tools: dpkg, the low-level foundation everything else in the Debian ecosystem is built on.