dpkg — Low Level Package Manager in Debian Ecosystem

dpkg operates on one already-present .deb file at a time — it has no concept of a remote repository, doesn’t resolve dependencies, and won’t download anything. What it does do is the actual, authoritative work of installing, removing, and querying packages, including maintaining the package database from the last chapter. Every higher-level operation you’ll do with apt in the next chapter ultimately calls down into dpkg to do this part.

Installing A Local Package File

sudo dpkg -i somepackage.deb

-i (install) unpacks the archive, copies its files onto the system, runs its maintainer scripts, and registers it in the package database. If somepackage.deb depends on something not currently installed, dpkg will report the problem clearly but won’t fix it for you — no repository lookup, no automatic download. This limitation is exactly why apt, covered next, exists as a wrapper around this same underlying mechanism.

Removing And Purging

sudo dpkg -r somepackage

-r (remove) uninstalls the package’s files, but deliberately leaves configuration files behind under /etc — a deliberate design choice, on the assumption you might reinstall the same software later and want your previous configuration intact.

sudo dpkg -P somepackage

-P (purge) goes further, removing configuration files as well — the actual “get back to zero” operation, not just -r. This distinction between remove and purge is genuinely important and comes up constantly in real administration; a later chapter in this section covers it in full, including where the two commands can still leave things behind even after a purge.

Package States: Reading dpkg -l

dpkg -l

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version        Architecture   Description
ii  bash            5.2.15-2ubuntu1 amd64         GNU Bourne Again SHell
rc  oldpackage      1.0.0-1        amd64          (config files remain)

That two-letter code at the start of each line is worth being able to read on sight:

Seeing a lot of rc entries in dpkg -l output is a genuinely common real finding — it means something was removed but never purged, and its old configuration is still sitting under /etc taking up space and creating confusion about whether it’s “really” gone.

Listing Every File A Package Owns: dpkg -L

This is the package database from the last chapter, made directly queryable — exactly the mechanism that makes complete, confident removal possible at all.

dpkg -L bash

/.
/bin
/bin/bash
/usr/share/doc/bash
/usr/share/doc/bash/changelog.Debian.gz
/usr/share/man/man1/bash.1.gz

Every single file this package placed on the system, listed exactly — genuinely the authoritative answer to “what did installing this actually do to my filesystem.”

Reverse Lookup: Which Package Owns This File?

The opposite direction is just as useful, and comes up constantly during real troubleshooting — you’ve found a file, and you want to know what installed it:

dpkg -S /bin/bash

bash: /bin/bash

Genuinely handy the moment you’re investigating an unfamiliar binary or configuration file and want to know its origin before touching it.

Checking A Package’s Status Directly

dpkg -s bash

Package: bash
Status: install ok installed
Priority: required
Version: 5.2.15-2ubuntu1

More detail than the single-line dpkg -l entry — full metadata for one specific package.

Recovering From An Interrupted Install

Occasionally an install gets interrupted partway through — a system crash, a killed process — leaving dpkg’s database in a partially-configured state, visible as that iU status from the table above.

sudo dpkg --configure -a

-a (all) resumes configuration for every package left in this partial state, finishing whatever was interrupted rather than leaving it stuck. This is a genuinely common first troubleshooting step any time apt itself starts complaining about a broken or inconsistent package state.

What dpkg Deliberately Doesn’t Do

Worth restating plainly: dpkg has no concept of the internet. It can’t search for a package by name, it can’t fetch anything, and it can’t automatically resolve a missing dependency by pulling in whatever satisfies it. Every one of those capabilities is exactly what the next chapter’s tool, apt, adds on top of everything dpkg already does here.

What’s Next

You can now install, remove, purge, and query local .deb files directly, with a full, authoritative view of exactly what any given package has touched. The next chapter introduces apt — the tool you’ll actually reach for day to day, built as a repository-aware, dependency-resolving layer on top of everything dpkg does under the hood.