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 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
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
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.
RPM has five basic modes of operation (not counting package building): installing, uninstalling, upgrading, querying, and verifying. This section contains an overview of each mode. For complete details and options, try rpm --help or see rpm(8). Also, see Additional Resources for more information on RPM.
Installing and Upgrading Packages
RPM packages typically have file names in the following form:
For example the
tree-1.7.0-3.fc29.x86_64.rpm file name includes the package name (
tree), version (
1.7.0), release (
3), operating system major version (
fc29) and CPU architecture (
When installing a package, ensure it is compatible with your operating system and processor architecture. This can usually be determined by checking the package name. For example, the file name of an RPM package compiled for the AMD64/Intel 64 computer architectures ends with
--upgrade) option has two functions, it can be used to:
upgrade an existing package on the system to a newer version, or
install a package if an older version is not already installed.
The rpm -U package.rpm command is therefore able to either upgrade or install, depending on the presence of an older version of package.rpm on the system.
tree-1.7.0-3.fc29.x86_64.rpm package is in the current directory, log in as
root and type the following command at a shell prompt to either upgrade or install the tree package:
~]# rpm -Uvh tree-1.7.0-3.fc29.x86_64.rpm
Use -Uvh for nicely-formatted RPM installs
If the upgrade or installation is successful, the following output is displayed:
Preparing... ########################################### [100%] 1:tree ########################################### [100%]
Always use the -i (install) option to install new kernel packages!
rpm provides two different options for installing packages: the aforementioned
You should always use the
The signature of a package is checked automatically when installing or upgrading a package. The signature confirms that the package was signed by an authorized party. If the verification of the signature fails, an error message is displayed.
If you do not have the appropriate key installed to verify the signature, the message contains the word
warning: tree-1.7.0-3.fc29.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 431d51: NOKEY
See Checking Package Signatures for more information on checking package signatures.
Replacing Already-Installed Packages
If a package of the same name and version is already installed, the following output is displayed:
Preparing... ########################################### [100%] package tree-1.7.0-3.fc29.x86_64 is already installed
To install the package anyway, use the
--replacepkgs option, which tells RPM to ignore the error:
~]# rpm -Uvh --replacepkgs tree-1.7.0-3.fc29.x86_64.rpm
This option is helpful if files installed from the package were deleted or if you want the original configuration files to be installed.
If you attempt an upgrade to an older version of a package (that is, if a newer version of the package is already installed), RPM informs you that a newer version is already installed. To force RPM to perform the downgrade, use the --oldpackage option:
rpm -Uvh --oldpackage older_package.rpm
Resolving File Conflicts
If you attempt to install a package that contains a file that has already been installed by another package, a conflict message is displayed. To make RPM ignore this error, use the --replacefiles option:
rpm -Uvh --replacefiles package.rpm
Satisfying Unresolved Dependencies
RPM packages sometimes depend on other packages, which means that they require other packages to be installed to run properly. If you try to install a package that has an unresolved dependency, a message about a failed dependency is displayed.
Find the suggested package(s) on the Fedora installation media or on one of the active Fedora mirrors and add it to the installation command. To determine which package contains the required file, use the
rpm -q --whatprovides "required_file"
If the package that contains required_file is in the RPM database, the name of the package is displayed.
Although you can force rpm to install a package that has an unresolved dependency (using the
Preserving Changes in Configuration Files
Because RPM performs intelligent upgrading of packages with configuration files, you may see the following message:
saving /etc/configuration_file.conf as /etc/configuration_file.conf.rpmsave
This message means that the changes you made to the configuration file may not be forward-compatible with the new configuration file in the package, so RPM saved your original file and installed a new one. You should investigate the differences between the two configuration files and resolve them as soon as possible to ensure that your system continues to function properly.
Alternatively, RPM may save the package’s new configuration file as, for example,
configuration_file.conf.rpmnew and leave the configuration file you modified untouched. You should still resolve any conflicts between your modified configuration file and the new one, usually by merging changes from the old one to the new one, for example using the diff program.
Uninstalling a package is just as simple as installing one. Type the following command at a shell prompt as
rpm -e package
rpm -e and package name errors
Note that the command expects only the package name, not the name of the original package file. If you attempt to uninstall a package using the rpm -e command and provide the original full file name, you receive a package-name error.
You can encounter dependency errors when uninstalling a package if another installed package depends on the one you are trying to remove. For example:
~]# rpm -e ghostscript error: Failed dependencies: ghostscript is needed by (installed) ghostscript-cups-9.07-16.fc29.x86_64 ghostscript is needed by (installed) foomatic-4.0.9-6.fc29.x86_64 libgs.so.9()(64bit) is needed by (installed) libspectre-0.2.7-4.fc29.x86_64 libijs-0.35.so()(64bit) is needed by (installed) gutenprint-5.2.9-15.fc29.x86_64 libijs-0.35.so()(64bit) is needed by (installed) cups-filters-1.0.35-15.fc29.x86_64
Warning: Forcing Package Installation
Although you can force rpm to uninstall a package that has unresolved dependencies (using the
Freshening is similar to upgrading, except that only installed packages are upgraded. Type the following command at a shell prompt as
rpm -Fvh package.rpm
--freshen) option compares the versions of the packages specified on the command line with the versions of packages that are already installed on the system. When a newer version of an already-installed package is processed by the
--freshen option, it is upgraded to the newer version. However, the
--freshen option does not install a package if no previously-installed package of the same name exists. This differs from regular upgrading, as an upgrade installs all specified packages regardless of whether or not older versions of the packages are already installed.
Freshening works for single packages or package groups. For example, freshening can help if you download a large number of different packages, and you only want to upgrade those packages that are already installed on the system. In this case, issue the following command with the
*.rpm global expression:
~]# rpm -Fvh *.rpm
RPM then automatically upgrades only those packages that are already installed.
The RPM database stores information about all RPM packages installed on the system. It is stored in the
/var/lib/rpm/ directory and is used for many things, including querying what packages are installed, what version each package is, and for calculating changes to files in packages since their installation. To query this database, use the rpm command with the
rpm -q package_name
This command displays the package name, version, and release number of the installed package package_name. For example:
~]$ rpm -q tree tree-1.7.0-3.fc29.x86_64
Package Selection Options subheading in the rpm(8) manual page for a list of options that can be used to further refine or qualify your query. Use options listed below the
Package Query Options subheading to specify what information to display about the queried packages.
Verifying a package is comparing information about files on the system installed from a package with the same information from the original package. Among other parameters, verifying compares the file size, MD5 sum, permissions, type, owner, and the group of each file.
Use the rpm command with the
--verify) option to verify packages. For example:
~]$ rpm -V tree
Package Selection Options subheading in the rpm(8) manual page for a list of options that can be used to further refine or qualify your query. Use options listed below the
Verify Options subheading to specify what characteristics to verify in the queried packages.
If everything verifies properly, there is no output. If there are any discrepancies, they are displayed. The output consists of lines similar to these:
~]# rpm -V abrt S.5....T. c /etc/abrt/abrt.conf .M....... /var/spool/abrt-upload
The format of the output is a string of nine characters followed by an optional attribute marker and the name of the processed file.
The first nine characters are the results of tests performed on the file. Each test is the comparison of one attribute of the file to the value of that attribute as recorded in the RPM database. A single period (
.) means the test passed, and the question-mark character (
?) signifies that the test could not be performed. The following table lists symbols that denote specific discrepancies:
file size differs
mode differs (includes permissions and file type)
digest (formerly MD5 sum) differs
device major/minor number mismatch
readLink(2) path mismatch
user ownership differs
group ownership differs
The attribute marker, if present, describes the purpose of the given file. The following table lists the available attribute markers:
If you see any output, use your best judgment to determine if you should remove the package, reinstall it, or fix the problem in another way.
Finding and Verifying RPM Packages
Before using any RPM packages, you must know where to find them and be able to verify if you can trust them.
Finding RPM Packages
Although there are many RPM repositories on the Internet, for security and compatibility reasons, you should consider installing only official Fedora-provided RPM packages. The following is a list of sources for RPM packages:
Official Fedora installation media.
Official RPM repositories provided with the DNF package manager. See DNF for details on how to use the official Fedora package repositories.
Unofficial, third-party repositories not affiliated with The Fedora Project also provide RPM packages.
When considering third-party repositories for use with your Fedora system, pay close attention to the repository’s web site with regard to package compatibility before adding the repository as a package source. Alternate package repositories may offer different, incompatible versions of the same software, including packages already included in the Fedora repositories.
Checking Package Signatures
RPM packages can be signed using GNU Privacy Guard (or GPG), which helps you make certain that downloaded packages are trustworthy. GPG is a tool for secure communication. With GPG, you can authenticate the validity of documents and encrypt or decrypt data.
To verify that a package has not been corrupted or tampered with, check its GPG signature by using the rpmkeys command with the
rpmkeys -K package.rpm
Note that the DNF package manager performs automatic checking of GPG signatures during installations and upgrades.
GPG is installed by default, as well as a set of Red Hat keys for verifying packages. To import additional keys for use with RPM, see Importing GPG Keys.
Importing GPG Keys
To verify Red Hat packages, a Red Hat GPG key needs to be installed. A set of basic keys is installed by default. To view a list of installed keys, execute the following command at a shell prompt:
~]$ rpm -qa gpg-pubkey*
To display details about a specific key, use rpm -qi followed by the output from the previous command. For example:
~]$ rpm -qi gpg-pubkey-fd431d51-4ae0493b
Use the rpmkeys command with the
--import option to install a new key for use with RPM. The default location for storing RPM GPG keys is the
/etc/pki/rpm-gpg/ directory. To import new keys, use a command like the following as
~]# rpmkeys --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
See the Product Signing (GPG) Keys article on the Red Hat Customer Portal for additional information about Red Hat package-signing practices.
Common Examples of RPM Usage
RPM is a useful tool for both managing your system and diagnosing and fixing problems. See the following examples for an overview of some of the most-used options.
To verify your entire system and see what files are missing, issue the following command as
If some files are missing or appear corrupted, consider reinstalling relevant packages.
To determine which package owns a file, enter:
rpm -qf file
To verify the package that owns a particular file, enter as
rpm -Vf file
To locate documentation files that are a part of a package to which a file belongs, enter:
rpm -qdf file
To find information about a (non-installed) package file, use the following command:
rpm -qip package.rpm
To list files contained in a package, use:
rpm -qlp package.rpm
See the rpm(8) manual page for more options.
RPM is a complex utility with many options and methods for querying, installing, upgrading, and removing packages. See the following resources to learn more about RPM.
rpm --help — This command displays a quick reference of RPM parameters.
rpm(8) — The RPM manual page offers an overview of all available RPM parameters.
The RPM website — http://www.rpm.org/
The RPM mailing list — http://lists.rpm.org/mailman/listinfo/rpm-list
DNF describes how to use the DNF package manager to search, install, update, and uninstall packages on the command line.
Want to help? Learn how to contribute to Fedora Docs ›