Mastering .deb Installation: Practical Techniques Beyond dpkg -i

Dropped a vendor-provided .deb onto your Ubuntu LTS or Debian server? Most reach for:

sudo dpkg -i example-package.deb

Sure, it unpacks and places files, but neglects a key aspect—dependency resolution. Expect output like:

dpkg: dependency problems prevent configuration of example-package:
 example-package depends on libfoo2 (>=1.0); however:
  Package libfoo2 is not installed.

At this stage, the package is half-installed, and your APT state can be inconsistent. On a production machine, this is unacceptable.

Dependency Management: What Really Happens

Consider dpkg as a low-level tool: it installs the package, logs everything, but won't fetch missing dependencies or recommend alternatives. After a failed install, cleanup usually requires:

sudo apt-get install -f

This tells APT to repair broken dependencies—if those dependencies exist in active repositories. But if the .deb targets a different Debian release, things unravel fast.

Modern Approach: Let APT Do the Heavy Lifting

Since Debian 9 "Stretch" and Ubuntu 16.04, apt can directly process local files and all required package relationships:

sudo apt install ./example-package.deb

Key detail: The ./ or full path is necessary. Omitting it makes apt search for a package named literally example-package.deb in your remote repositories, which results in an error:

E: Unable to locate package example-package.deb

With the local file path, apt computes dependencies and pulls them before installing. Side effect: local installs are now part of regular APT history, visible with apt list --installed.

Alternative: gdebi for Single-file Installs

On minimal-base systems or legacy environments, gdebi offers targeted dependency resolution without excess:

sudo apt-get install gdebi-core
sudo gdebi ./example-package.deb

• Reads the .deb metadata.
• Resolves missing dependencies.
• Installs everything in a single pass.

GUI users can opt for gdebi-gtk. Caveat: gdebi does not track as part of standard apt history—expect minor audit blind-spots.

Edge Cases and Troubleshooting

Dependencies Not in Any Repo

Some .deb packages—especially from obscure vendors—require libraries missing from your enabled repositories. The install fails with:

The following packages have unmet dependencies:
 example-package : Depends: libbar1 (>=2.2.8) but it is not installable

Resolution options:

• Manually locate and install the required .deb for libbar1. Use with caution; version mismatches are easy.
• Add the vendor-provided repository (careful with signing keys and repository trust).
• Isolate via Docker or LXC when pollution of your base OS is not acceptable.

ABI or Distribution Mismatches

Installing a .deb intended for Debian Sid onto Debian Stable? Prepare for broken dependencies or, in rare cases, glibc conflicts. Use dpkg --force-depends only if you’re prepared to recover from partial package installs.

Inspecting .deb Files Before Committing

Blind installs cause surprises. Always audit package internals first:

dpkg -I example-package.deb     # Metadata and dependencies
dpkg -c example-package.deb     # File listing
ar x example-package.deb        # Extracts control/data tarballs for manual inspection

Practical tip: Scripts in DEBIAN/postinst may perform actions as root. Always check these when installing from outside official repositories.

Guidance for Clean Systems

• Prefer official repos or mature PPAs whenever possible. Local .deb installs complicate upgrades and audits.
• Scrutinize package origins. Unsigned binaries are a known attack vector.
• Record manual installations in /var/log or a configuration management tool. Ad-hoc package drift is costly in production.

Comparison: Installation Tools

Non-obvious: Purging Leftovers

After removing a .deb, residual config files can remain:

sudo apt-get remove --purge example-package

Or, examine /etc/ for stray config directories, especially after non-repo installs.

Final Considerations

Direct .deb installation has its risks. Only proceed with full knowledge of dependencies, origin, and control scripts. Placing .deb artifacts into configuration management—Ansible, Puppet, etc.—is strongly recommended for auditability and repeatability.

System stability depends less on the method and more on discipline in package sourcing and dependency hygiene. Sometimes, the right answer is: don’t install the .deb at all—seek a supported repository or containerize the application instead.