Understanding Linux Package Formats: .deb vs. .rpm

Linux software is distributed in two major package formats: .deb files used by Debian, Ubuntu, Linux Mint, and their derivatives, and .rpm files used by Fedora, Red Hat Enterprise Linux, CentOS, and their derivatives. Both formats bundle a program’s files, metadata, and dependency information into a single installable archive. The key difference is which package manager handles them: .deb packages use APT and dpkg, while .rpm packages use DNF and rpm. Neither format works natively on the other distribution family — a .deb file cannot be installed on Fedora, and a .rpm file cannot be installed on Ubuntu.

Introduction: Why Linux Has Two Package Worlds

When you install software on Linux through your package manager, it arrives as a package — a structured archive containing the program files, configuration, documentation, and instructions for how to install everything in the right place. The format of that package is not universal across all Linux distributions. Linux has two major package format families, each with a long history, a dedicated toolset, and a large ecosystem of distributions that use it.

The .deb format (Debian package) originated with the Debian project in 1993 and is used today by Debian, Ubuntu, Linux Mint, Pop!_OS, and hundreds of other Debian-derived distributions — collectively representing the majority of desktop Linux users. The .rpm format (RPM Package Manager, originally Red Hat Package Manager) originated with Red Hat Linux in 1997 and is used today by Fedora, Red Hat Enterprise Linux (RHEL), CentOS Stream, AlmaLinux, Rocky Linux, SUSE, and openSUSE — the dominant formats in enterprise Linux environments.

For most everyday Linux use, this distinction stays invisible. You run sudo apt install firefox or sudo dnf install firefox and the package manager handles everything. But understanding the formats themselves — what they contain, how they work, how to install a package file you downloaded directly, and how to inspect or query packages — turns you from a passive package manager user into someone who truly understands how Linux software deployment works. And there are real situations where this knowledge matters: installing software only available as a downloaded .deb or .rpm file, diagnosing installation problems, understanding what a package will do before installing it, or simply satisfying the curiosity that makes someone a better Linux user.

This article covers both formats thoroughly: their structure and contents, the tools used to manage them, practical installation and inspection commands, how they handle dependencies, and the key differences that have persisted through decades of Linux development.

What Is a Package?

Before comparing formats, establishing what a package is and why it exists provides essential context.

The Problem Packages Solve

Distributing software as raw source code requires every user to compile it — a process that demands development tools, can take significant time, and requires resolving compilation dependencies manually. Distributing software as bare executable files with no metadata creates chaos: no record of what is installed, no way to cleanly uninstall, no knowledge of which other software a program needs to function.

A package solves both problems by bundling the compiled software with everything needed to install, run, and remove it properly:

• The executable programs and libraries
• Configuration files and data files
• Documentation
• Metadata: the package name, version, description, maintainer, and license
• Dependency information: which other packages are required
• Installation scripts: commands to run before and after installation

This bundled format allows the package manager to install software reliably, track everything that was installed, remove it cleanly, and understand the relationships between packages — all automatically.

How Packages Relate to Repositories

Individual package files (.deb or .rpm) can be installed directly from disk. But the typical workflow uses repositories — servers that host collections of packages along with indexes describing what is available. Your package manager downloads packages from repositories automatically when you run apt install or dnf install. The package file itself is the same whether it came from a repository or was downloaded directly; what changes is the installation workflow.

The .deb Format: Debian’s Package System

History and Distribution

The .deb format was created by Ian Murdock for Debian Linux in 1993. When Ubuntu was founded in 2004 by Canonical, it chose Debian as its foundation and inherited the .deb format. Today, Debian and its derivatives form the largest single family of Linux distributions by user count, making .deb the format encountered by the largest share of desktop Linux users.

Distributions using .deb:

• Debian (the original)
• Ubuntu and all official Ubuntu flavors (Kubuntu, Xubuntu, Ubuntu MATE, etc.)
• Linux Mint
• Pop!_OS
• elementary OS
• Kali Linux
• Raspberry Pi OS
• Zorin OS
• Hundreds of less common derivatives

What a .deb File Contains

A .deb file is an ar archive (a Unix archive format) containing three components:

debian-binary — a plain text file containing the version of the Debian package format (currently 2.0). A simple version marker.

control.tar.* — a compressed tar archive containing control information:

• control — the most important file: package name, version, architecture, maintainer, description, and dependency information
• preinst — script run before installation begins (optional)
• postinst — script run after installation completes (optional)
• prerm — script run before removal begins (optional)
• postrm — script run after removal completes (optional)
• conffiles — list of files that should be treated as configuration (preserved during upgrades by default)
• md5sums — checksums for all installed files (for integrity verification)

data.tar.* — a compressed tar archive containing all the actual files to install, arranged in the filesystem structure they will occupy (e.g., usr/bin/firefox, usr/share/man/man1/firefox.1.gz, usr/share/applications/firefox.desktop).

The dpkg Tool: Direct Package Management

dpkg (Debian Package) is the low-level tool that actually installs, removes, and queries .deb packages. APT is the high-level tool that downloads packages from repositories and resolves dependencies — but APT uses dpkg under the hood for the actual installation.

Install a downloaded .deb file:

$ sudo dpkg -i package.deb

If the installation fails due to unmet dependencies, dpkg reports the missing packages but does not resolve them automatically. Fix dependency problems after a failed dpkg -i with:

$ sudo apt install -f

The -f (fix-broken) flag tells APT to resolve and install any unmet dependencies.

A cleaner alternative that handles dependencies automatically:

$ sudo apt install ./package.deb

Using apt install ./ (note the ./ prefix indicating a local file) invokes APT’s dependency resolution for local package files — the preferred method for installing downloaded .deb files.

Remove a package:

$ sudo dpkg -r package-name        # Remove but keep config files
$ sudo dpkg -P package-name        # Purge (remove including config files)

List all installed packages:

$ dpkg -l

Check if a specific package is installed:

$ dpkg -l package-name
$ dpkg -s package-name             # Full status information

List all files installed by a package:

$ dpkg -L package-name

This shows every file the package placed on your system — invaluable for understanding what a package does or finding where a configuration file lives.

Find which package installed a specific file:

$ dpkg -S /usr/bin/firefox
firefox: /usr/bin/firefox

Inspect a .deb file without installing it:

$ dpkg -I package.deb              # Show control information (metadata)
$ dpkg -c package.deb              # List files that would be installed

The control File: Package Metadata

The control file is the heart of a .deb package. Here is a real example from the curl package:

Package: curl
Version: 8.5.0-2ubuntu10.1
Architecture: amd64
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Installed-Size: 480
Depends: libc6 (>= 2.17), libcurl4 (= 8.5.0-2ubuntu10.1), zlib1g (>= 1:1.1.3)
Pre-Depends: dpkg (>= 1.17.5)
Suggests: libcurl4-doc, libcurl4-openssl-dev
Description: command line tool for transferring data with URL syntax
 curl is a command line tool for transferring data with URL syntax,
 supporting DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP,
 IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S, RTMP, RTMPS, RTSP,
 SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS.

Every field visible here is part of the package’s contract with the system: what it is, what version it is, what it needs to function, what it suggests, and what it provides.

The APT Ecosystem: High-Level .deb Management

APT (Advanced Package Tool) sits above dpkg and provides:

• Automatic dependency resolution and installation
• Repository management (updating package lists)
• Coordinated upgrades across all installed packages
• Clean removal of packages and their orphaned dependencies

APT’s key tools:

• apt — the primary user-facing command (combines apt-get and apt-cache functionality)
• apt-get — the original command-line tool (still widely used in scripts)
• apt-cache — queries the APT package cache and metadata
• apt-file — finds which package provides a specific file

The .rpm Format: Red Hat’s Package System

History and Distribution

The RPM format was created by Marc Ewing and Erik Troan at Red Hat in 1997. It was designed to address weaknesses in the earlier RPM Standalone Package format and has been continuously developed since. When Red Hat Enterprise Linux became the dominant enterprise Linux distribution, RPM became the de facto standard for enterprise Linux packaging.

Distributions using .rpm:

• Fedora (Red Hat’s community distribution)
• Red Hat Enterprise Linux (RHEL) — the dominant enterprise Linux
• CentOS Stream (the upstream of RHEL)
• AlmaLinux and Rocky Linux (RHEL-compatible community replacements for CentOS)
• SUSE Linux Enterprise Server (SLES)
• openSUSE
• Oracle Linux
• Amazon Linux

What a .rpm File Contains

An .rpm file uses a custom binary format with four sections:

Lead — a legacy header identifying the file as an RPM package and containing basic information. Largely superseded by the signature and header sections.

Signature — cryptographic signatures and checksums that verify the package has not been tampered with. When a package is signed by a trusted key (such as Red Hat’s GPG key), this section allows the package manager to verify authenticity before installation.

Header — extensive metadata including: package name, version, release, architecture, summary, description, license, URL, dependencies (Requires, Provides, Conflicts, Obsoletes), file list with attributes, pre/post installation scripts, and changelog.

Payload — the actual files to install, compressed using cpio format (historically) or newer compression.

The RPM format embeds more metadata directly in the binary file than .deb does, making it possible to query a .rpm file comprehensively without installing it.

The rpm Tool: Direct Package Management

rpm is the low-level RPM package management tool, directly analogous to dpkg.

Install a downloaded .rpm file:

$ sudo rpm -i package.rpm          # Basic install
$ sudo rpm -ivh package.rpm        # Install with verbose output and progress hash

Like dpkg -i, rpm -i does not automatically resolve dependencies. Use DNF for dependency-aware installation:

$ sudo dnf install ./package.rpm

Upgrade a package (install or upgrade):

$ sudo rpm -Uvh package.rpm        # Install if new, upgrade if already installed
$ sudo rpm -Fvh package.rpm        # Freshen: only upgrade if already installed

Remove a package:

$ sudo rpm -e package-name         # Erase (remove)
$ sudo rpm -e --nodeps package-name  # Remove ignoring dependencies (use carefully)

List all installed packages:

$ rpm -qa                          # Query all
$ rpm -qa | grep firefox           # Filter for specific package

Check if a package is installed:

$ rpm -q package-name
firefox-125.0.3-1.fc40.x86_64

If installed, shows the full package name including version. If not installed: “package package-name is not installed.”

Show detailed package information:

$ rpm -qi package-name             # Query information

List all files installed by a package:

$ rpm -ql package-name             # Query list

Find which package owns a file:

$ rpm -qf /usr/bin/firefox
firefox-125.0.3-1.fc40.x86_64

Inspect an .rpm file without installing:

$ rpm -qip package.rpm             # Info from package file
$ rpm -qlp package.rpm             # File list from package file
$ rpm -qRp package.rpm             # Dependencies (Requires) from package file

Verify package integrity:

$ rpm -V package-name              # Verify installed files match package

rpm -V checks that installed files have not been modified from the package’s original state — useful for security auditing or diagnosing unexpected behavior.

RPM Package Naming Convention

RPM packages follow a strict naming convention that encodes version information:

firefox-125.0.3-1.fc40.x86_64.rpm
│       │         │  │    │
│       │         │  │    └─ Architecture (x86_64, aarch64, noarch)
│       │         │  └────── Distribution tag (fc40 = Fedora 40)
│       │         └───────── Release number (packaging revision)
│       └─────────────────── Version
└─────────────────────────── Package name

The architecture field indicates which CPU architecture the package is built for:

• x86_64 — 64-bit Intel/AMD processors (most desktop/server Linux)
• aarch64 — 64-bit ARM processors (Raspberry Pi 4/5, Apple Silicon VMs)
• noarch — architecture-independent (scripts, data files, Python packages)
• i686 — 32-bit Intel processors (increasingly rare)

The DNF Ecosystem: High-Level .rpm Management

DNF (Dandified YUM) is the high-level package manager for RPM-based systems, equivalent to APT for .deb systems:

$ sudo dnf install package-name    # Install from repository
$ sudo dnf install ./package.rpm   # Install local .rpm file with dep resolution
$ sudo dnf remove package-name     # Remove
$ sudo dnf update                  # Update all packages
$ sudo dnf search keyword          # Search repositories
$ sudo dnf info package-name       # Show package information
$ dnf provides /usr/bin/file       # Find which package provides a file

SUSE uses a different high-level tool called zypper:

$ sudo zypper install package-name
$ sudo zypper remove package-name
$ sudo zypper update

Key Differences Between .deb and .rpm

Feature	.deb	.rpm
File extension	.deb	.rpm
Low-level tool	dpkg	rpm
High-level tool	apt / apt-get	dnf / zypper
Primary distributions	Debian, Ubuntu, Mint	Fedora, RHEL, SUSE
Internal format	ar archive	Custom binary
Dependency field name	Depends	Requires
Config file handling	Preserved by default (conffiles)	Marked with %config in spec
File verification	dpkg --verify / debsums	rpm -V
Changelog	Optional (in /usr/share/doc)	Embedded in package header
Find package for file	dpkg -S /path	rpm -qf /path
List installed packages	dpkg -l	rpm -qa
Query a file’s package	dpkg -I file.deb	rpm -qip file.rpm

Philosophical Differences

Beyond technical format differences, the two ecosystems have historically reflected different priorities:

Debian/Ubuntu (.deb) has traditionally emphasized stability, thorough testing before package inclusion, and user choice. Ubuntu LTS releases offer 5 years of support. Packages go through extensive testing cycles before reaching users. The Debian Free Software Guidelines strictly govern what software enters Debian’s main repository.

Red Hat/Fedora (.rpm) has emphasized enterprise readiness, security certifications, and the relationship between a community distribution (Fedora) that acts as an upstream for a supported enterprise product (RHEL). Fedora moves faster and includes newer software versions. RHEL provides 10-year support cycles with commercial backing.

Cross-Format Conversion: alien

The alien tool converts between package formats — .rpm to .deb and vice versa. This allows installing software packaged only for one distribution family on the other.

$ sudo apt install alien           # Install alien on Ubuntu/Debian

Convert .rpm to .deb:

$ sudo alien -d package.rpm        # Creates package.deb
$ sudo dpkg -i package.deb         # Install the converted package

Convert .deb to .rpm:

$ sudo alien -r package.deb        # Creates package.rpm

Convert and install in one step:

$ sudo alien -i package.rpm        # Convert and install immediately

Important caveats about alien:

Conversion works for simple packages but is not reliable for complex ones. Issues that commonly arise:

• Post-installation scripts written for the other distribution’s conventions may fail or cause unexpected behavior
• File paths may differ between distributions (the package may install files to wrong locations)
• Dependencies from one ecosystem do not translate to the other — the converted package may have no dependency information, leaving you to manually identify and install requirements
• System integration features (service installation, systemd unit files) may not work correctly

Use alien as a last resort when software is unavailable as a native package or Flatpak/Snap. For any software critical to system function, prefer native packages, Flatpak, or building from source.

Inspecting Packages Before Installing

Understanding what a package contains before installing it is good security and administrative practice.

Inspecting a .deb File

View package metadata:

$ dpkg -I downloaded_package.deb
 new Debian package, version 2.0.
 size 1234567 bytes: control archive=2345 bytes.
     512 bytes,    12 lines      control
     890 bytes,    45 lines      md5sums
 Package: software-name
 Version: 2.5.0-1
 Architecture: amd64
 Maintainer: Developer Name <dev@example.com>
 Installed-Size: 4500
 Depends: libc6 (>= 2.17), libstdc++6 (>= 9)
 Description: Software that does something useful

List files the package will install:

$ dpkg -c downloaded_package.deb

Extract and examine the control scripts without installing:

$ mkdir /tmp/pkg_inspect
$ dpkg-deb -e downloaded_package.deb /tmp/pkg_inspect/
$ ls /tmp/pkg_inspect/
control  md5sums  postinst  prerm
$ cat /tmp/pkg_inspect/postinst

Examining installation scripts before running them is important security practice for packages from unofficial sources.

Extract package files without installing:

$ dpkg-deb -x downloaded_package.deb /tmp/pkg_extract/
$ ls /tmp/pkg_extract/

Inspecting an .rpm File

View package metadata:

$ rpm -qip package.rpm
Name        : software-name
Version     : 2.5.0
Release     : 1.fc40
Architecture: x86_64
Install Date: (not installed)
Group       : Applications/Internet
Size        : 4608000
License     : MIT
Signature   : RSA/SHA256, Tue Feb 18 09:22:15 2026
Source RPM  : software-name-2.5.0-1.fc40.src.rpm
Summary     : Software that does something useful
Description : Software that does something useful with more detail here.

List files the package will install:

$ rpm -qlp package.rpm

View package dependencies:

$ rpm -qRp package.rpm

View package scripts:

$ rpm -qp --scripts package.rpm

Shows the pre-installation, post-installation, pre-removal, and post-removal scripts embedded in the package.

GPG Signatures: Trusting Packages

Both .deb and .rpm packages support cryptographic signing — a GPG (GNU Privacy Guard) digital signature that proves the package was created by a trusted source and has not been modified since signing.

Why Signatures Matter

When you install a package from your distribution’s official repositories, the package manager verifies the GPG signature automatically. An unsigned package or a package signed with an untrusted key triggers a warning. This signature verification is what prevents a compromised repository or man-in-the-middle attack from silently replacing packages with malicious versions.

Verifying .rpm Signatures

$ rpm --checksig package.rpm
package.rpm: digests signatures OK

Import a GPG key for signature verification:

$ sudo rpm --import https://developer.example.com/RPM-GPG-KEY

Verifying .deb Signatures

APT uses its own keyring (stored in /etc/.apt/keyrings/ or /usr/.share/keyrings/) to verify repository signatures. When you add a repository, you also add its GPG public key so APT can verify all packages from that repository.

For individual .deb files:

$ dpkg-sig --verify package.deb

Adding a repository GPG key (modern method):

$ curl -fsSL https://example.com/gpg.key | sudo gpg --dearmor -o /etc/.apt/keyrings/example.gpg

Package File vs. Repository Installation: When to Use Each

Most of the time, install software through your package manager from repositories. Download and install package files directly only in these situations:

The software is not in official repositories. Commercial software (Slack, Discord, VS Code, Google Chrome) often provides official .deb or .rpm files on their websites rather than maintaining a repository. These are legitimate and safe to install from official vendor websites.

You need a specific version. Your distribution’s repository may have an older version. If you need a newer version and neither Flatpak nor Snap nor a PPA provides it, the vendor’s package file may be the option.

You are in an air-gapped environment. Systems without internet access cannot pull from repositories. Packages must be downloaded separately and transferred.

Testing a package you are developing. When building your own packages, installing the .deb or .rpm directly is how you test them.

For all these cases, use sudo apt install ./package.deb or sudo dnf install ./package.rpm rather than dpkg -i or rpm -i directly — the apt/dnf approach automatically resolves and installs missing dependencies.

Conclusion: Two Mature Ecosystems

The .deb and .rpm formats represent decades of accumulated engineering effort toward the same goal: reliable, reproducible, manageable software distribution. Their differences are real but narrow in day-to-day use — both formats accomplish the same task effectively, and the choice between them is simply a consequence of which distribution family you use.

What matters most is understanding what a package is and what the tools do. Whether you are running dpkg -L nginx to see every file the nginx package installed, or rpm -qf /etc/.nginx/nginx.conf to discover which package owns a configuration file, or inspecting an installation script before running a package from an unfamiliar vendor — this knowledge makes you a more capable, more confident Linux user.

The package system is the foundation of how Linux software works. Understanding it at the format level, not just the apt install level, is the difference between using Linux and truly understanding Linux.