dpkg internals

dpkg is the engine; apt is the front-end. dpkg manages the local package database and installs/removes files. It knows nothing about repositories, mirrors, or dependency resolution across packages it has not yet downloaded. apt adds those layers on top: it fetches indexes, resolves the full dependency graph, downloads .deb files, and then hands them to dpkg in the correct order.

# Installing without apt — dpkg only
# (all dependencies must already be installed; dpkg will refuse if they are not)
sudo dpkg -i ./mypackage_1.2.3_amd64.deb

# dpkg -i error when a dependency is missing:
# dpkg: dependency problems prevent configuration of mypackage:
#  mypackage depends on libfoo3 (>= 3.1); libfoo3 is not installed.
# Use apt to resolve: sudo apt -f install

apt -f install (“fix broken”) tells apt to look at the current dpkg state, find missing dependencies, fetch them from a repository, and hand everything back to dpkg to complete configuration. This is the correct recovery path after a partial install.

The dpkg database lives in /var/lib/dpkg/ and is plain text. The most important files:

# The status file — one entry per installed/known package
cat /var/lib/dpkg/status | head -40

# info/ directory — per-package metadata and maintainer scripts
ls /var/lib/dpkg/info/nginx.list       # list of all files installed by nginx
cat /var/lib/dpkg/info/nginx.postinst  # post-install script (runs after dpkg unpacks)

# Query the database: list installed packages
dpkg -l                    # all installed packages
dpkg -l 'nginx*'           # filter by pattern
dpkg -l | grep '^ii'       # only fully installed (ii = installed, not half-configured)

The status field prefix in dpkg -l output reads as two letters: the first is the desired state (i=install, r=remove, p=purge), the second is the current state (i=installed, c=config-files only, H=half-installed). A line starting with iH means dpkg tried to install but got interrupted before configuration finished.

A .deb archive is an ar archive containing three members. You can inspect it without installing:

# Examine a .deb without installing it
ar t nginx_1.18.0-6ubuntu14_amd64.deb
# Output:
#   debian-binary    ← "2.0\n" — format version marker
#   control.tar.xz  ← metadata, dependency declarations, maintainer scripts
#   data.tar.xz     ← the actual filesystem tree to unpack

# Extract and inspect control.tar
ar x nginx_1.18.0-6ubuntu14_amd64.deb control.tar.xz
tar --list -f control.tar.xz
# ./control        ← package name, version, arch, dependencies
# ./conffiles      ← list of config files that survive purge
# ./preinst        ← runs BEFORE unpacking
# ./postinst       ← runs AFTER unpacking (typically starts the service)
# ./prerm          ← runs BEFORE removal
# ./postrm         ← runs AFTER removal

The maintainer scripts (pre/post install/remove) are shell scripts that run as root. This is why package authenticity (GPG signing) matters — a malicious postinst in a tampered package runs arbitrary code with root privileges at install time.

dpkg -L and dpkg -S let you navigate the ownership graph. These are the two most useful dpkg queries for incident investigation:

# List all files installed by a package
dpkg -L nginx
# /usr/sbin/nginx
# /etc/nginx/nginx.conf
# /lib/systemd/system/nginx.service
# ...

# Find which package owns a file
dpkg -S /usr/sbin/nginx
# nginx: /usr/sbin/nginx

# Check if a file on disk belongs to any package
dpkg -S /etc/nginx/nginx.conf.bak
# dpkg-query: no path found matching pattern /etc/nginx/nginx.conf.bak
# (it was created by the operator, not a package — safe to edit or delete)

# Verify package integrity: check installed files against expected checksums
dpkg -V nginx
# (no output = all files match; differences printed per file)

dpkg -V runs md5 checksums of every file listed in the package manifest against what is on disk. A modified config file will show up — useful for detecting unauthorized changes to system files.

The half-configured state is the most common dpkg emergency. It happens when an install is interrupted after unpacking but before the postinst script completes. The package is on disk but dpkg has not registered it as fully configured.

# Symptoms — any apt command fails with:
# E: dpkg was interrupted, you must manually run:
#      sudo dpkg --configure -a

# Fix: tell dpkg to finish configuring anything that was interrupted
sudo dpkg --configure -a

# If postinst itself fails (e.g. the service fails to start), you may need:
sudo dpkg --configure -a --force-confdef --force-confnew

# Nuclear option: remove the half-installed package and start over
sudo dpkg --remove --force-remove-reinstreq badpackage
sudo apt install badpackage   # re-fetch and install cleanly

The --force-remove-reinstreq flag removes a package even though dpkg considers it in a reinstreq (reinstall required) state. Use it only when --configure -a fails — it can leave files on disk that you then need to clean up manually.