Linux online course

RPM Package Manager in Linux

Learn how to identify, install, query, verify, upgrade, and remove RPM packages, understand RPM filenames, and handle dependencies safely.

RPM is both a package format and a low-level command-line package-management system used by many Linux distributions. An RPM package is a file containing software files, metadata, dependency requirements, and often installation scripts. The rpm command installs, removes, queries, verifies, and upgrades those packages.

This lesson covers direct RPM operations and explains when a higher-level tool such as DNF, YUM, or zypper is safer and more convenient.

What RPM Is

RPM originally referred to the package format and is now commonly used for the complete package-management system. A package is a distributable unit of software and metadata. It can contain executables, libraries, configuration files, documentation, version information, dependencies, and scripts that run during installation or removal.

There are three related things to distinguish:

• RPM package file: A file ending in .rpm, such as example-2.4-1.x86_64.rpm.
• rpm command: The low-level command-line utility used to operate on package files and installed packages.
• RPM database: The local database that records installed package names, versions, files, ownership, dependencies, scripts, and other metadata.

RPM supports installation, removal, querying, verification, and upgrades. It is not itself a complete repository service: the basic command normally works with packages already available on the local system.

RPM-Based Linux Distributions

RPM is used across several Linux families. Examples include Red Hat Enterprise Linux, Fedora, CentOS Stream and historical CentOS releases, SUSE Linux Enterprise, openSUSE, Mandriva, and many specialized derivatives.

The basic package format, database concepts, and many rpm options are broadly shared. However, repository configuration and high-level package-management commands differ. Red Hat and Fedora systems commonly use DNF, with YUM retained as a historical or compatibility interface. SUSE and openSUSE commonly use zypper.

RPM Package Filename Convention

A typical RPM filename follows this general form:

name-version-release.architecture.rpm

For example:

kdessh-4.3.5-0.3.3.x86_64.rpm

• kdessh is the package name.
• 4.3.5 is the upstream software version.
• 0.3.3 is the package release or build revision.
• x86_64 indicates a 64-bit x86 target.
• .rpm identifies the package file format.

Package names can contain hyphens, so manually splitting a filename at every hyphen is not always reliable. RPM metadata queries are safer. RPM package identity is also often described with NEVRA: Name, Epoch, Version, Release, and Architecture. The epoch may not appear in the filename.

Common Architecture Labels

• x86_64: 64-bit Intel or AMD x86 systems.
• aarch64: 64-bit ARM systems.
• i686: 32-bit x86 systems.
• noarch: Architecture-independent content, often scripts, documentation, or data.
• src: Source package content rather than a directly installable binary package.

Use uname -m to inspect the running system's machine architecture. A package should normally match the system and its installed-library environment.

Inspecting a Local RPM Before Installation

Use -qip to query metadata in an RPM file that is not installed:

rpm -qip ./package-name-version-release.x86_64.rpm

This can show the package summary, version, release, architecture, description, packager, installation size, and requirements. It reads the package file; it does not query the installed RPM database and does not install anything.

To check signature and digest information for a downloaded package, use:

rpm --checksig ./package-name-version-release.x86_64.rpm

Signature checking helps assess package origin and integrity. It is different from file verification, which examines files after a package has been installed.

Installing Local RPM Files

The -i operation installs a local package:

sudo rpm -ivh ./package-name-version-release.x86_64.rpm

• -i: Install.
• -v: Produce verbose output.
• -h: Display progress marks while processing the package.

Installing software normally requires administrative privileges, so use sudo or an appropriate root shell. A plain install is intended for a package that is not already installed. If the same package identity is already present, RPM generally reports that the package is already installed instead of installing it again.

Before installing, inspect the metadata, check the architecture, confirm the source is trusted, and consider whether a repository-aware package manager should handle the operation instead.

Upgrading and Freshening Packages

The -U operation upgrades a package when an older version is installed and also installs the package when it is absent:

sudo rpm -Uvh ./package-name-version-release.x86_64.rpm

This behavior makes -U useful when the desired result is “ensure this package version is installed.” It replaces an older package version according to RPM's package rules.

The -F operation, called freshen, updates a package only if a version of that package is already installed:

sudo rpm -Fvh ./package-name-version-release.x86_64.rpm

A freshen operation does not install a package that is absent. Upgrade operations are often preferred to a plain -i when applying a package update, because they handle both the replacement case and, for -U, the not-yet-installed case.

Querying Installed Packages and Package Files

The -q option queries the local RPM database. For example:

rpm -q package-name

If the package is installed, the result normally includes its installed name and version-release. Otherwise, RPM reports that the package is not installed. The name used here is the installed package name, not necessarily the complete downloaded filename.

Use -qi for detailed information about an installed package:

rpm -qi package-name

This commonly displays the summary, version, release, architecture, installation date, packager, vendor, size, and description.

Useful Query Variations

• rpm -ql package-name lists files supplied by an installed package.
• rpm -qf /usr/bin/example-command identifies the installed package that owns a file.
• rpm -qR package-name displays dependency requirements declared by an installed package.
• rpm -qip ./package-name-version-release.x86_64.rpm queries an uninstalled local RPM file.

The distinction between rpm -qi package-name and rpm -qip file.rpm is important: the first reads records for an installed package from the RPM database, while the second reads metadata embedded in a local package file.

Common RPM Package-Management Operations

Removing Packages

Use -e, meaning erase, to remove an installed package:

sudo rpm -e package-name

Use the installed package name rather than the downloaded filename. Query the database first if you are unsure:

rpm -q package-name

RPM checks dependencies during removal. If another installed package requires the package being erased, removal is normally blocked to prevent broken software. Do not casually bypass this protection with --nodeps. Removing a required library or capability can break multiple applications and may make later repairs more difficult.

Verifying Installed Packages

The -V operation compares installed package files and recorded metadata against the information stored in the RPM database:

rpm -V package-name

Verification can reveal missing files, changed checksums, size differences, permission changes, ownership changes, and other metadata differences. A changed configuration file may be intentional, so verification output requires context rather than automatic replacement.

Verification is not the same as signature checking. rpm --checksig file.rpm examines signature and digest information for a package file before installation. rpm -V package-name examines the installed contents against recorded package information after installation.

Dependencies and Higher-Level Package Managers

A dependency is another package, library, capability, or version requirement needed for software to install or run correctly. Direct rpm operations check dependency requirements, but the low-level command does not normally search repositories and download missing dependencies automatically.

Higher-level package managers combine RPM packages with repository metadata and dependency resolution:

• DNF: Common on modern Fedora and Red Hat-family systems.
• YUM: A historical and compatibility interface on Red Hat-family systems.
• zypper: Common on SUSE Linux Enterprise and openSUSE.

For example, on a DNF-based system, install a local RPM while allowing dependencies to come from enabled repositories with:

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

Direct RPM use is appropriate for inspecting a package file, installing a self-contained local package, performing low-level administration, or troubleshooting package database and file ownership issues. For normal software installation and updates, prefer the distribution's repository-aware package manager.

Safe Command-Line Practices

• Inspect package metadata and architecture before installation with rpm -qip.
• Use trusted package sources and check signature information with rpm --checksig.
• Prefer DNF, YUM, or zypper for normal repository-based installation and updates.
• Use exact installed package names when erasing packages.
• Avoid --nodeps and --force unless a documented recovery procedure specifically requires them.
• Review command output and retain the package source, version, and release information when troubleshooting.
• Check the system architecture with uname -m and compare it with the package architecture.

Troubleshooting RPM Operations

Missing Dependencies

If installation fails because dependencies are missing, the usual cause is that direct rpm does not fetch packages from repositories. Use DNF, YUM, or zypper as appropriate, or obtain the required dependencies through a supported method. Avoid solving the error with --nodeps unless you are following a specific recovery procedure.

Incompatible Architecture

If RPM reports an architecture mismatch, compare the system and package architectures:

uname -m
rpm -qip ./package.rpm

Obtain a matching package. A noarch package is suitable only when its contents are genuinely architecture-independent.

Package Already Installed

A plain -i operation may fail when the same package is already installed. Check the installed version with rpm -q package-name. Use -U for an intended upgrade, or use the distribution's normal package manager.

Removal Blocked by Dependencies

Dependency errors during removal mean that other installed software requires the package. Identify the dependent software and remove or replace it through the higher-level package manager when appropriate. Avoid --nodeps, which can leave the system inconsistent.

Wrong Name Used for Removal

A complete filename such as package-1.0-1.x86_64.rpm is not always the correct argument to rpm -e. Query installed package records and use the installed package name.

Untrusted or Damaged Download

If a package cannot be trusted or appears damaged, reacquire it from a trusted source and run rpm --checksig. Do not install a package whose origin or integrity cannot be established.

Unexpected Verification Changes

Verification differences may result from intentional configuration edits, changed permissions, replaced executables, or missing files. Investigate unexpected changes and repair through supported package-management procedures rather than blindly forcing an installation.

Exam-Relevant Summary

• .rpm is a package file; the rpm command and RPM database manage and track installed packages.
• -i installs, -U upgrades or installs, and -F freshens only already-installed packages.
• -q queries installed package records; -qip queries an uninstalled local file.
• -ql lists package files, -qf finds the owner of an installed file, and -qR lists requirements.
• -e erases an installed package by package name.
• -V verifies installed files and metadata; --checksig checks a package file's signature and digest information.
• Direct RPM checks dependencies but does not normally resolve and download them from repositories.
• DNF/YUM and zypper are higher-level tools for repository access and dependency resolution.