Mastering .deb Files: Running and Managing Debian Packages with Precision

Deployment pipelines and operational debugging often hit a wall with package management. When the standard apt install workflow isn't enough—wrong version, no network, or a custom build—the ability to handle .deb packages directly becomes essential.

Anatomy of a .deb File

A .deb package is an ar(1) archive, generally structured as:

<package>.deb
├── control.tar.{gz,xz}
├── data.tar.{gz,xz}
└── debian-binary (typically "2.0")

• control.tar.gz: package metadata, pre/post install scripts (postinst, prerm, etc.), manifest
• data.tar.gz: all files to be installed, with their absolute paths
• debian-binary: version of the Debian package standard

Note: Avoid installing arbitrary .deb files without inspection—scripts can do anything as root.

Use Cases for Direct .deb Handling

• Reproducing bugs with a specific application version (e.g., libssl1.1_1.1.1f-1ubuntu2.16_amd64.deb)
• Replacing system packages inside airgapped environments
• Installing vendor software distributed only as .deb (e.g., Google Chrome, Docker CE)
• Postmortem analysis—autopsying a failing upgrade or broken dependency chain

Practical Example: Installing Google Chrome Manually

Download the latest release:

wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb

Sanity check the package:

dpkg-deb -I google-chrome-stable_current_amd64.deb
# Output: Package: google-chrome-stable
#         Version: 126.0.6478.126-1
#         Depends: libc6 (>= 2.17), ...

Inspect contents—verify no surprises:

dpkg-deb -c google-chrome-stable_current_amd64.deb | less
# /usr/bin/google-chrome-stable, /opt/google/chrome/, etc.

Installing with dpkg

Install .deb (no dependency resolution):

sudo dpkg -i google-chrome-stable_current_amd64.deb

If dependencies are missing:

dpkg: dependency problems prevent configuration of google-chrome-stable:
 google-chrome-stable depends on fonts-liberation; however:
  Package fonts-liberation is not installed.

Repair with apt:

sudo apt-get install -f

This instructs APT to resolve unmet dependencies and finish configuration—critical on Debian-based systems, otherwise packages remain only "half-installed" (dpkg -l shows iU status).

Uninstalling and Purging .deb Packages

Removal:

sudo dpkg -r google-chrome-stable

Leaves residual configs in /etc/opt/. For full cleanup:

Complete purge:

sudo dpkg -P google-chrome-stable

Be aware this nukes user/system configs; useful in CI or test environments to guarantee stateless cleanup.

Advanced dpkg Usage

Extract without install:
Useful for forensic or targeted file grabs—sometimes all you need is a single binary.

dpkg-deb -x google-chrome-stable_current_amd64.deb ./chrome-extract/

Reconfigure installed package:
If install scripts failed but the package is present:

sudo dpkg-reconfigure google-chrome-stable

Does nothing here—Chrome isn’t packaged with Debconf—but for others (e.g., tzdata), the dialog resets the configuration.

Force install/removal (use with caution):

sudo dpkg --force-all -i package.deb
sudo dpkg --force-remove-reinstreq -r broken-package

Executing these can leave the system with unresolved dependencies or dangling links. Not recommended unless absolutely necessary, e.g., when automating destructive test harnesses or in recovery mode.

Non-Obvious Lessons from the Field

• Side note: dpkg maintains no dependency database—only state transitions. Always follow up with apt-get install -f after manual installs on production machines.
• Gotcha: Manually installed packages aren’t auto-updated by apt upgrade. Security fixes require you to track upstream releases or re-package internally—important for compliance.
• Alternative: For bulk scripting, gdebi is often easier, as it auto-resolves dependencies on install. Not installed by default on minimal Debian systems.

Summary Table

Additional Reference

• Debian Policy Manual 5.4: Binary packages
• For custom builds, consider dpkg-buildpackage and lint with lintian before signing and distributing.

There are edge cases that no FAQ covers—partial failures, missing triggers, or conflicting maintainer scripts. In practice, blending dpkg for surgery and apt for dependency management covers most real-world needs. Sometimes, the best engineering solution is knowing when not to reinstall.