How To Install A Deb File In Ubuntu

How To Install A Deb File In Ubuntu

Reading time1 min
#Ubuntu#Linux#OpenSource#DebianPackages#PackageManagement#SysAdmin

Mastering the Installation of .deb Files in Ubuntu: Beyond the Basics

Consider a classic problem: you need to deploy a proprietary monitoring agent on Ubuntu 22.04, only available as a .deb from the vendor. No PPA, no repo. You can't use apt-get to gloss over the details—every action must be deterministic and auditable.


The Anatomy of a .deb

A .deb archive is more than just binaries. Each package includes:

  • data.tar.gz: The actual files (binaries, libraries, configs)
  • control.tar.gz: Package scripts and metadata (postinst, prerm, dependencies)
  • debian-binary: Format version (current: 2.0)

Inspect contents before proceeding:

ar x example-package_1.2.3_amd64.deb
tar -xf data.tar.gz
tar -xf control.tar.gz

Engineer’s note: Many breakages originate from incomplete or malicious postinst scripts. Always review the postinst and prerm if you’re running untrusted software.


Direct Installation: dpkg

Simple install:

sudo dpkg -i example-package_1.2.3_amd64.deb

If dependencies are missing, you’ll find:

dpkg: error processing package example-package (--install):
 dependency problems - leaving unconfigured

Here, dpkg is intentionally dumb: it lays down files but skips resolver logic. Your workflow should be:

  1. Run dpkg -i
  2. Repair unmet dependencies
    sudo apt-get install -f
    

This triggers apt to resolve and configure missing dependencies.


apt: Smarter, Safer

Since Ubuntu 18.04, apt accepts local .deb files and resolves dependencies automatically.

sudo apt install ./example-package_1.2.3_amd64.deb

The ./ avoids confusion—otherwise, apt assumes a repo package.

Side effect: apt will hold the package if a newer version appears in the repository, unless you pin it. Check with:

apt-cache policy example-package

Preinstall Audit: Extract, Inspect, Simulate

Blind installation rarely works on “controlled” hosts. Instead:

ActionCommand
Extract filesdpkg-deb -x example-package_1.2.3_amd64.deb ./unpacked/
Grab controldpkg-deb -e example-package_1.2.3_amd64.deb ./unpacked/DEBIAN
Dry runsudo dpkg --dry-run -i example-package_1.2.3_amd64.deb

Check for, e.g., postinst scripts that touch critical files, or any unknown systemd unit activations.


Dependency Hell, Non-Standard Repos

A typical snag: you need libfoo1 >= 2.1.0, but this dependency isn’t in any repo.

Identify dependencies:

dpkg-deb -f example-package_1.2.3_amd64.deb Depends
# Or for full metadata:
dpkg-deb -I example-package_1.2.3_amd64.deb

Resolutions:

  • Manual fetch from packages.ubuntu.com. Validate checksums; stale mirrors are not rare.
  • Install the required dependencies:
    sudo dpkg -i libfoo1_2.1.0_amd64.deb
    sudo dpkg -i example-package_1.2.3_amd64.deb
    
  • Or use gdebi if you want minimal automation on dependency resolution:
    sudo apt install gdebi-core
    sudo gdebi example-package_1.2.3_amd64.deb
    
    Note: gdebi won’t handle circular dependency loops or non-repo edges.

Clean Uninstall

To remove:

sudo apt remove example-package

Purge configs as well:

sudo apt purge example-package

List installed files (sometimes needed for verifying system drift):

dpkg -L example-package

Known issue: dpkg can leave orphaned configuration files if you’ve manually manipulated /etc.


Non-obvious Tip: Version Freezing & Rollback

Pin a manually-installed package to prevent accidental upgrade:

sudo apt-mark hold example-package

If you must roll back, and you have the prior .deb, apply:

sudo dpkg -i example-package_1.2.2_amd64.deb

Check that no residual configs skew old/new behavior.


Summary

Direct .deb handling is fundamental when exact version pinning, offline installs, troubleshooting, or compliance audits are at stake. Don’t trust graphical updaters or “one click” scripts—verify what a package will do to your filesystem, ensure you have all required dependencies present, and validate removal paths up front.

For actual deployments: Keep a local cache of .deb files, document SHA256 checksums, and script your install/removal actions exactly as you want them to run in CI or on production assets. Anything less risks silent drift.


Sample scenario:
To test, fetch a package (e.g., htop_3.0.5-7build2_amd64.deb), extract it with dpkg-deb -x, scan the control files, install via apt, and confirm via dpkg -L htop what landed on disk.

Avoid surprises—make .deb a first-class tool, not a black box.