dpkg is the low-level package manager of Debian and its derivatives, including Ubuntu and Linux Mint. In Linux package management, it is the tool that actually unpacks .deb archives, runs their maintainer scripts and records every installed file in a local database. It works on individual package files and does not download packages or resolve dependencies; those tasks belong to higher-level front ends such as APT.
The name stands for Debian package. Every package operation on a Debian-based system, whether started from apt, a graphical software center or an automation tool, ends in a call to dpkg, which makes it the authoritative record of what is installed.
How dpkg installs a package
A .deb file is an ar archive with three members: debian-binary with the format version, control.tar with metadata and scripts, and data.tar with the files to install. dpkg reads the control data, checks declared dependencies and conflicts against its database, and refuses or defers the installation if they are not satisfied.
Installation proceeds in two distinct phases, unpacking and configuring, and each phase can run maintainer scripts.
| Phase | What happens | Scripts involved |
|---|---|---|
| Unpack | Files are extracted and old versions replaced | preinst, then the old prerm and postrm when upgrading |
| Configure | Configuration files are set up and services prepared | postinst configure |
| Remove | Program files are deleted, configuration kept | prerm, postrm remove |
| Purge | Configuration files are deleted as well | postrm purge |
Files listed in conffiles receive special protection. If the administrator has changed such a file and the new package version ships a different one, dpkg stops and asks whether to keep the local version or install the maintainer version, saving the alternative with a .dpkg-dist or .dpkg-old suffix.
The dpkg database and package states
dpkg keeps its state in /var/lib/dpkg. The file status lists every known package with its version and state, and the directory info/ holds the file lists, checksums and maintainer scripts of each installed package. Because this database is plain text, it is easy to inspect but easy to damage by manual edits.
| State | Meaning | Typical cause |
|---|---|---|
| installed | Unpacked and configured successfully | Normal completed installation |
| unpacked | Files present, not yet configured | Interrupted run or deferred configuration |
| half-configured | postinst started but failed | Error in a maintainer script |
| half-installed | Unpacking started but did not finish | Disk full or crash during unpack |
| config-files | Only configuration files remain | Package removed but not purged |
The two-letter codes in dpkg -l output combine the desired action and the current state. ii means the package should be installed and is installed, rc means it was removed with configuration files left, and iU signals an unpacked but unconfigured package that needs attention.
Essential dpkg commands
dpkg is rarely used to install software directly, but its query functions are indispensable for administration and troubleshooting.
| Command | Purpose |
|---|---|
| dpkg -i file.deb | Install or upgrade a local package file |
| dpkg -r name | Remove a package and keep its configuration |
| dpkg -P name | Purge a package including configuration |
| dpkg -l pattern | List packages with their state and version |
| dpkg -L name | List the files a package installed |
| dpkg -S /path | Find which package owns a file |
| dpkg –configure -a | Finish configuring all unpacked packages |
| dpkg-deb -c file.deb | Show the contents of a package file |
Related helpers extend dpkg. dpkg-query offers custom output formats for scripts, dpkg-reconfigure reruns the configuration questions of a package, dpkg --verify compares installed files with their recorded MD5 checksums, and dpkg-divert redirects a packaged file to another path so that local replacements survive upgrades.
dpkg compared with APT and other package tools
Linux package management is layered: a low-level tool handles files and the local database, and a high-level tool handles repositories and dependency resolution. dpkg occupies the low layer on Debian systems in the same way that RPM does on Red Hat systems.
| Tool | Layer | Package format | Resolves dependencies |
|---|---|---|---|
| dpkg | Low level | .deb | No, only checks them |
| APT | High level, uses dpkg | .deb | Yes, from repositories |
| RPM | Low level | .rpm | No, only checks them |
| DNF | High level, uses RPM libraries | .rpm | Yes, from repositories |
| Pacman | Single tool for both layers | .pkg.tar.zst | Yes, from repositories |
The practical consequence is that dpkg -i on a package with missing dependencies leaves it unpacked and unconfigured. Running apt install ./file.deb instead lets APT fetch the missing packages first and then call dpkg, which is the recommended way to install local .deb files.
Pitfalls and recovery
Because dpkg holds an exclusive lock on its database, only one package operation can run at a time. Errors such as “could not get lock /var/lib/dpkg/lock-frontend” usually mean that another tool, often an automatic update service, is still running, not that the system is broken.
- After an interrupted upgrade, run
dpkg --configure -aand thenapt -f installto complete pending work. - Do not delete lock files while another package process is active; doing so can corrupt the database.
- Avoid
--force-alland similar options; they bypass safety checks and frequently create inconsistent states. - Keep backups of
/var/lib/dpkg/status; Debian already rotates copies in/var/backups. - Mixing packages from unrelated distribution releases creates dependency conflicts that dpkg reports but cannot solve.
In simple terms
dpkg is the installer and record keeper of Debian and Ubuntu. When it receives a software package, it puts every file in the right place, runs the setup steps and writes down exactly what it did.
It does not go shopping for missing parts, however. That job belongs to APT, which finds and downloads everything a program needs and then hands the packages to dpkg. Put together, APT plans the work and dpkg carries it out.
A practical example
A system administrator notices an unfamiliar file, /usr/lib/x86_64-linux-gnu/libfoo.so.3, on an Ubuntu server and needs to know where it came from. Running dpkg -S /usr/lib/x86_64-linux-gnu/libfoo.so.3 names the owning package immediately, and dpkg -L on that package lists all of its other files.
Later the same week, a kernel upgrade is interrupted by a power failure. On reboot, apt refuses to work and reports that dpkg was interrupted. The administrator runs dpkg --configure -a, which finishes configuring the half-installed packages, followed by dpkg --verify to confirm that no installed files differ from their checksums. The server returns to a consistent state within minutes and without reinstalling anything.