VMware ESXi and vSphere Cluster Management

RPM Package Manager: Installing, Querying, and Removing Linux Packages

Learn how to use the rpm command to install, inspect, query, verify, upgrade, and remove packages on RPM-based Linux distributions.

RPM is both a software package format and a low-level command-line package-management system. RPM packages are used by many Linux distributions to distribute applications, libraries, documentation, configuration files, and system components.

This lesson covers the rpm command for working with local package files and the installed RPM database. You will also learn when to use higher-level tools such as dnf, yum, and zypper.

What RPM Is

An RPM package is a distributable unit of software. A package normally contains:

  • Program binaries, libraries, scripts, documentation, and configuration files.
  • Metadata such as the package name, version, release, architecture, summary, description, and license.
  • Installation and removal scripts that run at specific stages of package management.
  • Dependency declarations describing required packages or capabilities.
  • Package ownership information that records which package supplied each installed file.

The rpm command is the low-level utility used to install, query, verify, upgrade, and erase RPM packages.

It is important to distinguish two related things:

  • An RPM package file: a file such as example-2.4-3.x86_64.rpm that can be copied, downloaded, inspected, or installed.
  • The RPM database: the local database containing records for packages currently installed on the system, including their metadata and managed files.

Querying an RPM file does not mean that the package is installed. Use the -p query modifier when the object of the query is a package file rather than the installed database.

RPM-Based Linux Distributions

RPM is the underlying package format in several distribution families, including:

  • Red Hat Enterprise Linux (RHEL).
  • Fedora.
  • CentOS-derived systems and other Enterprise Linux distributions.
  • SUSE Linux Enterprise.
  • openSUSE.
  • Mandriva-family systems and their derivatives.
  • Specialized enterprise and appliance distributions that use RPM packages.

The package format may be shared, but the preferred front end differs by distribution. RHEL, Fedora, and many related systems commonly use dnf; older systems may use yum. SUSE systems commonly use zypper. These higher-level tools use repositories and can resolve dependencies, while rpm primarily performs direct, low-level package operations.

RPM Package Filename Convention

A common RPM filename follows this pattern:

name-version-release.architecture.rpm

Package name: Identifies the software, such as kdessh.

Version: The upstream software version, such as 4.3.5.

Release/build: The revision assigned by the distribution or package builder, such as 0.3.3. This is separate from the upstream version.

Architecture: The CPU platform targeted by the package, such as x86_64, aarch64, or i686. noarch means the package is architecture-independent, often because it contains scripts, documentation, or other data.

RPM file extension: The .rpm suffix identifies the file as an RPM package file.

Reading an Example Filename

kdessh-4.3.5-0.3.3.x86_64.rpm
  • Name: kdessh
  • Version: 4.3.5
  • Release: 0.3.3
  • Architecture: x86_64
  • Extension: .rpm

Do not rely entirely on splitting a filename at hyphens. Package names themselves can contain hyphens, so use RPM metadata to confirm the identity:

rpm -qip kdessh-4.3.5-0.3.3.x86_64.rpm

NEVRA and Package Identity

NEVRA is a more complete package identity consisting of Name, Epoch, Version, Release, and Architecture. The epoch is an optional package-management value used when version comparison needs an override. It may not appear plainly in the filename, but RPM metadata can display it.

Installing a Local RPM File

Use the install action, -i, with a local package file:

sudo rpm -ivh package-name-version-release.arch.rpm
  • -i installs the package.
  • -v enables more verbose output.
  • -h displays hash marks as a progress indicator.
  • sudo supplies the administrative privileges normally required to modify system software.

A successful installation records the package in the local RPM database and places its files in the paths specified by the package.

Installation can fail when required dependencies are missing, the package architecture is incompatible, or an installed package conflicts with it. The low-level rpm command does not automatically download dependency packages.

Confirming an Installation

rpm -q package-name

A result containing the package name and version-release indicates that the package is registered in the installed RPM database. If the package is not installed, RPM reports that the package is not installed.

Common rpm Actions

Install a local package: rpm -ivh file.rpm. Acts on an RPM file. Check dependencies, architecture, source, and signature first.

Upgrade a local package: rpm -Uvh file.rpm. Acts on an RPM file and may replace an older installed version. Confirm compatibility before using it.

Query an installed package: rpm -q package-name. Acts on the installed RPM database. Use the installed package name, not the downloaded filename.

Query an RPM file: rpm -qip file.rpm. Acts on a package file without installing it.

List package files: rpm -ql package-name or rpm -qlp file.rpm. The first queries installed files; the second lists files inside an uninstalled package file.

Find file ownership: rpm -qf /path/to/file. Acts on a path known to the installed RPM database.

Verify an installed package: rpm -V package-name. Compares managed files with recorded package metadata.

Erase an installed package: sudo rpm -e package-name. Acts on the installed package name and checks dependencies before removal.

Querying Installed Packages

Check Installation and Version-Release

rpm -q package-name

For example:

rpm -q bash

This commonly prints a result similar to bash-5.1.8-6.el9.x86_64. The exact output depends on the distribution and installed release.

Display Detailed Metadata

rpm -qi package-name

The -i query format displays information such as the name, epoch, version, release, architecture, summary, vendor, license, installation date, size, and full description.

List Installed Files

rpm -ql package-name

This is useful when you need to locate an executable, manual page, configuration file, library, or documentation file supplied by a package.

Find Which Package Owns a File

rpm -qf /usr/bin/example-command

Package ownership answers the question, “Which installed RPM supplied this file?” The path must refer to a file recorded in the installed RPM database. If a command is found through PATH, first locate it with a shell tool such as command -v, then pass the resulting path to rpm -qf.

List All Installed RPM Packages

rpm -qa

The -a query selects all installed packages. You can combine it with standard shell filtering when searching a large list:

rpm -qa | grep -i python

Inspecting an Uninstalled RPM File

Use the -p modifier to query a package file directly. This lets you inspect a downloaded RPM before changing the system.

Read Package Information

rpm -qip package-name-version-release.arch.rpm

Review the package name, version, release, architecture, vendor, summary, description, and other metadata.

List Included Files

rpm -qlp package-name-version-release.arch.rpm

This command shows what the package would install without installing it.

Show Required Dependencies

rpm -qRp package-name-version-release.arch.rpm

The output lists required packages, libraries, or capabilities. It is useful for diagnosing why a standalone installation may fail.

Check a Package Signature

rpm --checksig package-name-version-release.arch.rpm

A GPG signature is a cryptographic signature used to validate package origin and integrity. A signature result is meaningful only when the signing key is trusted and came from an appropriate distribution or software source. Do not treat an unknown or failed signature as safe.

Removing Installed Packages

RPM uses erase mode, -e, to remove an installed package:

sudo rpm -e package-name

Use the installed package name, not the RPM filename. For example, use bash, not bash-5.1.8-6.el9.x86_64.rpm.

Before removal, inspect the package and its files:

rpm -qi package-name
rpm -ql package-name

RPM checks whether other installed packages require the package being erased. If a dependency error occurs, identify the dependent software and remove or replace it through the distribution's supported package manager. Avoid force options or dependency bypasses: removing a required library can break other applications or leave the system in an inconsistent state.

Upgrading, Downgrading, and Replacing Packages

Use upgrade mode for a local package when it is intended to replace an older installed package:

sudo rpm -Uvh package-name-version-release.arch.rpm

Unlike a simple install, upgrade mode is designed to install the new package while replacing an older version when the package identity and version relationship are appropriate. It can also install a package when no older version is present, depending on RPM behavior and package state.

A downgrade replaces a newer installed package with an older build. A replacement may also involve changing vendors, package names, or distribution builds. These operations can affect dependencies, configuration files, ABI compatibility, and future updates. Check package metadata and compatibility first, and prefer the distribution package manager when the package comes from a configured repository.

Verifying Installed Package Files

RPM records checksums, permissions, ownership, sizes, and other metadata for many managed files. Verification compares the current installed state with those records:

rpm -V package-name

No output commonly means that RPM found no differences worth reporting. Output indicates a difference, such as a changed checksum, altered permissions, a missing file, or a changed file size. The exact verification indicators are position-based, so consult the local rpm documentation for the complete indicator legend.

Configuration files are a common source of expected differences because administrators intentionally edit them. A verification result should therefore be investigated rather than automatically treated as proof of damage. Review the reported path, determine whether the change was intentional, and restore or reinstall unexpected changes using supported procedures.

Dependency Management Limitations

A dependency is a library, package, or capability required for software to install or run correctly. The low-level rpm command checks dependency declarations, but it does not normally search repositories and retrieve missing dependencies automatically.

Installing a local package: rpm can install a local file directly. dnf, yum, and zypper can also install local files while integrating dependency handling.

Dependency resolution: rpm reports missing requirements. Higher-level tools calculate a dependency transaction and obtain required packages from configured repositories.

Repository searching: rpm searches only local package records and files. Higher-level tools can search repository metadata.

Repository updates: rpm does not manage repository update workflows. Higher-level tools select compatible updates and handle transactions.

Package metadata queries: rpm provides detailed local and file-based queries. Higher-level tools provide repository and transaction metadata in addition to local information.

Signature and source workflow: rpm can inspect signatures, but repository tools usually integrate trusted keys, source selection, and policy checks more completely.

For a local RPM on a DNF-based system, a dependency-aware command is often preferable:

sudo dnf install ./package-name-version-release.arch.rpm

Use the equivalent supported tool for the distribution, such as zypper on SUSE systems. For normal repository installation and updates, use the distribution's package manager rather than manually downloading individual RPM files.

Safe Operational Practices

  • Confirm the package name, version, release, architecture, and intended distribution before installing a local file.
  • Obtain packages from a trusted source and validate the GPG signature with a trusted key.
  • Inspect metadata, included files, and requirements before installation when the source is unfamiliar.
  • Use package queries before removal to understand what is installed and which files the package owns.
  • Avoid force, replacement, and dependency-bypass options unless you have a documented recovery plan and understand the consequences.
  • Prefer supported repositories and high-level package managers for system updates, dependency resolution, and routine maintenance.
  • Keep backups or recovery access available before modifying core system packages.

Troubleshooting Common Problems

Failed Dependencies

Symptom: Installation reports failed dependencies.

Cause: The RPM requires packages or capabilities that are not installed.

Response: Inspect the requirements with rpm -qRp file.rpm, then use the distribution's dependency-aware package manager to install the local package or its requirements.

Incompatible Architecture

Symptom: RPM reports an incompatible architecture.

Cause: The package was built for a different CPU platform than the host.

Response: Check the host and package architectures. Obtain a matching build, or use a noarch package when the software is genuinely architecture-independent.

Removal Blocked by Dependencies

Symptom: Erase mode reports that another package requires the package.

Cause: Installed software declares a dependency on the package.

Response: Identify the dependent software and remove or replace it through the high-level package manager. Do not casually bypass the dependency check.

Package Is Installed but a Command Is Missing

Cause: The executable may have a different name or location, or the package may contain only libraries, documentation, or data.

Response: Run rpm -ql package-name, look for executable paths, and verify that the relevant directory is in the user's PATH.

Verification Reports Changed Files

Cause: A configuration file may have been intentionally edited, or a package-managed file may have been altered or removed.

Response: Review the paths and verification indicators. Preserve intentional configuration changes and restore unexpected modifications through supported package-management procedures.

The Local Package Cannot Be Trusted

Cause: The source or signing key is unknown, or signature verification fails.

Response: Do not install the package until its source and signature have been validated using the distribution's trusted key and package workflow.

Quick Reference

# Install a local RPM
sudo rpm -ivh file.rpm

# Upgrade or install a local RPM
sudo rpm -Uvh file.rpm

# Query an installed package
rpm -q package-name

# Show detailed installed metadata
rpm -qi package-name

# List files from an installed package
rpm -ql package-name

# Find the installed package that owns a file
rpm -qf /path/to/file

# Inspect an RPM file without installing it
rpm -qip file.rpm

# List files inside an RPM file
rpm -qlp file.rpm

# Show requirements in an RPM file
rpm -qRp file.rpm

# Verify installed files
rpm -V package-name

# Erase an installed package
sudo rpm -e package-name

For related package-management study, see RPM Package Manager.