Product SiteDocumentation Site


The RPM Package Manager (RPM) is an open packaging system that runs on Fedora as well as other Linux and UNIX systems. Red Hat and the Fedora Project encourage other vendors to use RPM for their own products. RPM is distributed under the terms of the GPL (GNU General Public License).
The RPM Package Manager only works with packages built in the RPM format. RPM itself is provided as the pre-installed rpm package. For the end user, RPM makes system updates easy. Installing, uninstalling, and upgrading RPM packages can be accomplished with short commands. RPM maintains a database of installed packages and their files, so you can make queries and verify installed files on your system. There are several applications, such as DNF or PackageKit, that can make working with packages in the RPM format even easier.

Use DNF Instead of RPM Whenever Possible

For most package-management tasks, the DNF package manager offers equal and often greater capabilities and utility than RPM. DNF also performs and tracks complicated system-dependency resolutions. DNF maintains the system integrity and forces a system integrity check if packages are installed or removed using another application, such as RPM, instead of DNF. For these reasons, it is highly recommended that you use DNF instead of RPM whenever possible to perform package-management tasks. See Chapter 6, DNF.
If you prefer a graphical interface, you can use the PackageKit GUI application, which uses DNF as its back end, to manage your system's packages.
During upgrades, RPM handles configuration files carefully, so that you never lose your customizations — something that you cannot accomplish with regular .tar.gz files.
For the developer, RPM enables software source code to be packaged into source and binary packages for end users. This process is quite simple and is driven from a single file and optional patches that you create. This clear delineation between pristine sources and your patches along with build instructions eases the maintenance of the package as new versions of the software are released.


Because RPM can make changes to the system itself, performing operations like installing, upgrading, downgrading, and uninstalling binary packages system-wide requires root privileges in most cases.

A.1. RPM Design Goals

To understand how to use RPM, it is helpful to understand the design goals of RPM:
With RPM, you can upgrade individual components of your system without a complete reinstallation. When you get a new release of an operating system based on RPM, such as Fedora, you do not need to reinstall a fresh copy of the operating system on your machine (as you might need to with operating systems based on other packaging systems). RPM allows for intelligent, fully-automated, in-place upgrades of your system. In addition, configuration files in packages are preserved across upgrades, so you do not lose your customizations. There are no special upgrade files needed to upgrade a package because the same RPM file is used to both install and upgrade the package on the system.
Powerful Querying
RPM is designed to provide powerful querying options. You can perform searches on your copy of the database for packages or even just certain files. You can also easily find out what package a file belongs to and where the package came from. The files an RPM package contains are in a compressed archive, with a custom binary header containing useful information about the package and its contents, allowing you to query individual packages quickly and easily.
System Verification
Another powerful RPM feature is the ability to verify packages. It allows you to verify that the files installed on the system are the same as the ones supplied by a given package. If an inconsistency is detected, RPM notifies you, and you can reinstall the package if necessary. Any configuration files that you modified are preserved during reinstallation.
Pristine Sources
A crucial design goal was to allow the use of pristine software sources, as distributed by the original authors of the software. With RPM, you have the pristine sources along with any patches that were used, plus complete build instructions. This is an important advantage for several reasons. For instance, if a new version of a program is released, you do not necessarily have to start from scratch to get it to compile. You can look at the patch to see what you might need to do. All the compiled-in defaults, and all of the changes that were made to get the software to build properly, are easily visible using this technique.
The goal of keeping sources pristine may seem important only for developers, but it results in higher quality software for end users.