Querying Installed Packages

Chapter 4
dpkg Deep Dive
Querying what's installed, inspecting package contents, and the manual install/repair operations apt alone can't do

Chapter 2 introduced dpkg as the low-level engine underneath apt. This chapter covers using it directly — genuinely useful for specific diagnostic and repair tasks that apt's higher-level interface doesn't expose at all.

Querying Installed Packages

$ # List every installed package
$ dpkg -l
ii nginx 1.22.1-9 amd64 small, powerful, scalable web server
ii openssh-server 1:9.2p1-2 amd64 secure shell (SSH) server

$ # Check if one specific package is installed
$ dpkg -l | grep nginx

$ # Detailed status of one specific package
$ dpkg -s nginx
Status: install ok installed
Version: 1.22.1-9

Decoding the Status Column

ii
Installed, correctly configured
rc
Removed, config files remain (Chapter 2's remove vs purge)
un
Unknown — never installed
iU
Installed but the configuration step failed — needs attention

Inspecting What Files a Package Actually Owns

$ # List every file installed by a package
$ dpkg -L nginx
/etc/nginx
/etc/nginx/nginx.conf
/usr/sbin/nginx

$ # The reverse — which package owns a specific file
$ dpkg -S /usr/sbin/nginx
nginx-core: /usr/sbin/nginx
dpkg -S is genuinely useful for "what installed this file?" mysteries
Tracking down which package is responsible for a specific binary or config file on a system you didn't fully set up yourself — or just confirming whether a file is genuinely part of a package or was placed there manually — is exactly what dpkg -S answers directly, rather than guessing.

Working with .deb Files Directly

$ # Install a standalone .deb file (e.g. downloaded directly from a vendor's site)
$ sudo dpkg -i some-package.deb

$ # If it fails due to missing dependencies, apt can resolve and finish the job
$ sudo apt --fix-broken install
dpkg -i does NOT resolve dependencies — that's the whole reason apt exists on top of it
Installing a .deb file directly with dpkg often fails partway through with unmet dependency errors, since dpkg has no repository awareness or dependency-resolution logic at all (Chapter 1) — that's exactly the gap apt fills. The standard recovery, shown above, hands the partially-installed state to apt, which can then pull in whatever dependencies are missing and complete the installation correctly.

Repairing a Broken Package State

CommandUse when
sudo dpkg --configure -aA package was interrupted mid-install (e.g. power loss) and is stuck "half-configured"
sudo apt --fix-broken installDependencies are unmet or inconsistent after a manual dpkg -i
sudo dpkg --remove --force-remove-reinstreq <pkg>A genuinely stuck package refuses normal removal — last resort, use cautiously
$ # The classic recovery sequence after an interrupted install
$ sudo dpkg --configure -a
$ sudo apt --fix-broken install
$ sudo apt update && sudo apt upgrade

Listing Files in a .deb Without Installing It

$ dpkg -c some-package.deb
drwxr-xr-x root/root 0 2026-01-01 ./etc/
-rw-r--r-- root/root 1234 2026-01-01 ./etc/myapp.conf

A genuinely useful inspection step before installing something from an unfamiliar source — seeing exactly what files a package would place, and where, without committing to the installation at all.

Chapter 4 Quick Reference

  • dpkg -l — list all installed packages; dpkg -s — detailed status of one specific package
  • Status codes: ii (installed OK), rc (removed, config remains), un (never installed), iU (failed configuration)
  • dpkg -L — files a package owns; dpkg -S — which package owns a given file (reverse lookup)
  • dpkg -i — installs a standalone .deb file directly, but does NOT resolve dependencies
  • apt --fix-broken install — the standard follow-up to resolve dependencies after a dpkg -i failure
  • dpkg --configure -a — fixes packages stuck mid-install after an interruption
  • dpkg -c — inspect a .deb's file contents without actually installing it
  • Next chapter: RPM-based systems — dnf/yum on RedHat/Fedora, installing/removing/upgrading