RPM installation and management

Certify and Increase Opportunity.
Be
Govt. Certified Linux Administrator

Package Management

Contemporary distributions of Linux-based operating systems install software in pre-compiled “packages” which contain (for most systems) binaries of software, configuration files, and in most systems, information about dependencies. Furthermore, package management tools keep track of updates and upgrades so that we don’t have to hunt down information about bug and security fixes.

Without package management, users must ensure that all of the required dependencies for a piece of software are installed and up to date, compile the software from the source code (which takes time and introduces compiler-based variances from system to system), and manage configuration for each piece of software. Additionally, without package management, application files are located in the (hopefully) standard locations for the system to which the developer(s) are accustomed, regardless of what system you’re using. In short, this becomes an utter mess.

Package management systems attempt to solve these problems, and are the tools through which developers attempt to increase the overall quality and coherence of a Linux-based operating system. Pursuant to these goals the features that (most) package management applications provide are:

• Package downloading: operating system projects provide repositories of packages which allow users to download their packages from a single, cryptographically-trusted provider. When you download from a package manager, the software can be authenticated and will remain in the repository even if the original “upstream” source becomes unreliable.
• Dependency resolution: packages contain meta-data which provides information about what other packages are required by the package in question. This allows applications and their dependencies to be installed with one command, and for programs to rely on common shared libraries, reducing bulk and allowing the operating system to manage updates to the packages.
• A standard binary package format: packages are prepared in a uniform way across the system in order to make installation easier and more coherent. While some distributions share formats–eg. Debian and Ubuntu both use .deb; CentOS, Fedora, Mandrivia and OpenSuSE use .rpm–there can be substantial compatibility issues between similarly formatted packages for different operating systems.
• Common installation and configuration locations: System developers often have conventions for how applications are configured and the layout of files in the /etc/ and /etc/init.d/ directories; by using packages, systems are able to enforce this conformity.
• Additional system-related configuration and functionality: Occasionally, operating system developers will develop patches and helper scripts for their software which get distributed in the packages. These modifications range from minimal to more substantive and can have a great impact on usability and user experience.
• Quality control. Operating system developers use the packaging process to test and ensure that the software is stable and free of bugs that might encroach upon product quality, and that the software doesn’t cause the system to become unstable. The subjective judgments and community standards that guide packaging and package management to a great extent guide the “feel” and “stability” of a given system.

RPM

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.

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.

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.

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

Installing and Upgrading – RPM packages typically have file names in the following form – package_name-version-release-operating_system-CPU_architecture.rpm For example the tree-1.7.0-3.fc22.x86_64.rpm file name includes the package name (tree), version (1.7.0), release (3), operating system major version (fc22) and CPU architecture (x86_64).

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 x86_64.rpm. The -U (or –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. Assuming the tree-1.7.0-3.fc22.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.fc22.x86_64.rpm

The -v and -h options (which are combined with -U) cause rpm to print more verbose output and display a progress meter using hash signs.

If the upgrade or installation is successful, the following output is displayed:

Preparing…               ########################################### [100%]

1:tree                   ########################################### [100%]

rpm provides two different options for installing packages: the aforementioned -U option (which historically stands for upgrade), and the -i option (which historically stands for install). Because the -U option includes both install and upgrade functions, the use of rpm -Uvh with all packages, except kernel packages, is recommended.

You should always use the -i option to install a new kernel package instead of upgrading it. This is because using the -U option to upgrade a kernel package removes the previous (older) kernel package, which could render the system unable to boot if there is a problem with the new kernel. Therefore, use the rpm -i kernel_package command to install a new kernel without replacing any older kernel packages.

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 NOKEY:

warning: tree-1.7.0-3.fc22.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 431d51: NOKEY

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.fc22.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.fc22.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

Uninstalling Packages – Uninstalling a package is just as simple as installing one. Type the following command at a shell prompt as root:

rpm -e package

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.

Freshening Packages – Freshening is similar to upgrading, except that only installed packages are upgraded. Type the following command at a shell prompt as root:

rpm -Fvh package.rpm

The -F (or –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.

The following table list options for the major operations with the rpm command

Option	Usage
-a, –all	Query all packages
-c, –configfiles	List configuration files
–changelog	List changelog entries
–conflicts	List capabilities this package conflicts with
-d, –docfiles	List documentation files
–dump	Dump out extra information on files.
-f, –file filename	Query for packages owning given file
–filesbypapkg	List all files in each selected package
–fileid md5_id	Query for the package with the given MD5 digest
-g, –group group_name	Query packages in the given group
–hdrid sha1_header_id	Query for the package with the given header identifier number, in SHA1 format
-i, –info	Display a lot of package information including description
–last	Reorder the output of the rpm command to show the most recently installed packages first
–obsoletes	List capabilities this package obsoletes
-p, –package rpm_file	Query the given package file or files
–pkgid md5_id	Query for the package with the given MD5 package ID
–provides	List capabilities provided by package
–querybynumber number	Query for the given entry, by number, in the RPM database
–qf, –queryformat format	Use the given query format for displaying the output
–redhatprovides capability	Look in rpmdb-redhat database for packages that provide the given capability
–redhatrequires capability	Look in rpmdb-redhat database for packages that require the given capability
-R, –requires	Lists packages and capabilities that this package depends on
–specfile specfile	Query the given spec file
-s, –state	Display the state of the listed files
–scripts	List scripts in the package
–tid transaction_id	Query for the package or packages with the given transaction ID
–triggeredby package	Query packages triggered by the given package
–triggers, –triggerscripts	List trigger scripts
–whatrequires capability	Query packages that require the given capability
–whatprovides capability	List packages that provide the given capability

Debian and Ubuntu Package Management

The Debian package management system, based on a tool called dpkg with the very popular apt system is an incredibly powerful, popular, and useful method of package management. In addition to Debian 5 (known as “Lenny”) a number of other prominent distributions of GNU/Linux are derived from the Debian system, most notably the Ubuntu family of distributions.

As a result these instructions are applicable for Debian and Ubuntu systems. While Debian and derived systems are not necessarily binary-compatible, .debs packaged for Debian are often compatible with Ubuntu (though this is not a supported workflow). Let’s begin by reviewing some basic commands.

Advanced Packaging Tool, (apt) – Chances are good that you’re already familiar with apt-get, a command which uses the “advanced package tool” to interact with the operating system’s underlying package system. The most relevant and useful commands are, (to be run as root):

• apt-get install [package-name] – This command installs the package(s) specified, along with any dependencies.
• apt-get remove [package-name] – This command removes the package(s) specified, but does not remove dependencies.
• apt-get autoremove – This command removes any “orphaned” dependencies which remain installed but are not used by any applications.
• apt-get clean – Removes downloaded package files (.deb) for software that are already installed.
• apt-get purge [optional] – Combines the functions of remove and clean for a specific package. Also removes configuration files for the given package.
• apt-get update – Reads the /etc/apt/sources.list file and updates the system’s database of packages available for installation. Run this after changing sources.list.
• apt-get upgrade – Upgrades all packages if there are updates available. Run this after running apt-get update.

While apt-get likely provides the most often used functionality of the package management, apt provides additional information that you may find useful in the apt-cache command.

• apt-cache search [package-name] – If you know the name of a piece of software but apt-get install fails or points to the wrong software, use search to look for other possible names, if you need to find out the name of a package that you know is in the system.
• apt-cache show [package-name] – The search interface only provides package names. If you need to learn more about a package, including dependency information, version numbers and a basic description, run this.
• apt-cache depends [package name(s)] – Lists the packages that the specified packages depends upon in a tree. These are the packages that will be installed with the apt-get install command.
• apt-cache rdepends [package name(s)] – Generates and outputs a list of packages that that depend upon the specified package. This list can often be rather long.
• apt-cache pkgnames – Generates a list of the currently installed packages on your system. This list is often rather long, so it is best to pipe its output through a command like less.

In general, combining most of these commands with apt-cache show can provide you with a lot of useful information about your system, the software that you might want to install, and the software that you have already installed.

aptitude – aptitude is another front-end interface for apt. It provides a graphical command line (via ncurses) interface to apt, which you might find useful for an easier approach to daily administrative tasks. In addition to the graphical interface, aptitude provides a combined command line interface for most apt functionality. The salient commands are:

• aptitude update, aptitude install, aptitude remove, aptitude clean, aptitude purge – Same as their apt-get counterparts.
• aptitude search, aptitude show, – Same as their apt-cache counterparts.
• aptitude download – Downloads a .deb file for a given package into the current directory.

Aptitude also includes advanced functionality for “safe” upgrading (an upgrade that doesn’t remove existing packages), as well as preventing the system from upgrading specific packages (“holding”). If this kind of functionality would be useful for you we encourage you to use the aptitude interface.

/etc/apt/sources.list – The file /etc/apt/sources.list controls which repositories apt constructs its database from. This file contains lines in the following format:

deb [location-of-resources] [distribution] [component(s)]

Here are some examples:

deb http://mirror.cc.columbia.edu/pub/linux/debian/debian/ lenny main contrib

deb http://emacs.orebokech.com lenny main

The first line specifies the Columbia University mirror for the “Lenny” distribution (Debian 5.0, Stable Release 14 February 2009), as well as the main and contributed components. The next line specifies the emacs.orebokech.com repository for Lenny, which provides regularly updated packages for emacs-snapshot (versions of emacs23, built from the current CVS tree), and its main component.

In general one does not want to add new entries to sources.list without a lot of scrutiny and diligence, as updating the package cache with additional repositories and running upgrades can sometimes result in the installation of broken packages, unmet dependencies, and system instability. In Debian systems, downgrading is often difficult.

For Debian systems, the repository names can either refer to the distribution code name (version specific; eg. lenny for current-stable, squeeze for testing, sid for unstable, etch for old-stable) or to a specific branch (eg, oldstable, stable, testing, unstable).

The component section of the line divides the repository based on how much support the developers of the operating system are able to offer for the contained packages (eg. main vs. contrib), or if the software is considered “free-software” or simply freely-distributable (eg. non-free). The layout of sources.list is a bit different in Ubuntu systems. The lines are in the same format but the names of the distributions and components are different:

• Ubuntu versions have a different naming scheme. Version 8.10 is named hardy in sources.list, 9.04 is jaunty, and 9.10 is karmic. These names follow an alphabetical pattern.
• Ubuntu components are: “main” and “restricted” for supported free and non-free packages; “universe” and “multiverse” for unsupported free and non-free software.

Using dpkg – apt-get and apt-cache are merely front-ends that provide a more usable interface, and connections to repositories for the underlying package management tools called dpkg and debconf. These tools are quite powerful, and fully documenting their functionality is beyond the scope of this document. However, a basic understanding of how to use these tools is useful. The most useful commands are:

• dpkg -i [package-file-name].deb – Installs a .deb file.
• dpkg –list [search-pattern] – Lists packages currently installed on the system.
• dpkg –configure – Runs a configuration interface to set a package up.
• dpkg-reconfigure – Runs a configuration interface on an already installed package.

Fedora and CentOS Package Management

Fedora and CentOS are closely related distributions, being upstream and downstream (respectively) from Red Hat Enterprise Linux. Their main differences stem from how packages are chosen for inclusion in their repositories. From a package management perspective the tools are very similar.

Both systems use the yum program as a front end to interact with system repositories and install dependencies, and also include a lower level tool called rpm which allows you to interact with individual rpm packages. Many operating systems aside from RedHat and Fedora use rpm packages. These include OpenSuSE, AIX, and Mandriva; while it may be possible to install an RPM packaged for one operating system on another, this is not supported or recommended, and the results of this action can vary greatly.

Yellow Dog Updater, Modified (yum) – The yum tool was initially developed for the Yellow Dog Linux system as a replacement for the then-default Yellow Dog Updater (yup). RedHat found the yum tool to be a valuable addition to their systems. Today yum is the default package and repository management tool for a number of operating systems.

From the command line, you can use the following subset of commands to interact with yum:

• yum install [package-name(s)] – This command installs the specified package(s) along with any required dependencies.
• yum erase [package-name(s)] – This command removes the specified package(s) from your system.
• yum search [search-pattern] – The search command searches the list of package names and descriptions for packages that match the search pattern and provides a list of package names, with architectures and a brief description of the package contents. Note that regular expression searches are not permitted.
• yum deplist [package-name] – deplist provides a listing of all of the libraries and modules that the named package depends on, along with the names of the packages (including versions) that provide those dependencies.
• yum check-update – This command refreshes the local cache of the yum database so that dependency information and the latest packages are always up to date.
• yum info [package-name] – The results of the info command provides the name, description of the package, as well as a link to the upstream home page for the software, release versions and the installed size of the software.
• yum reinstall [package-name(s)] – This command erases and then downloads a new copy of the package file and re-installs the software on your system.
• yum localinstall [local-rpm-file] – This command checks the dependencies of an .rpm file and then installs it.
• yum update [optional-package-name] – Downloads and installs all updates including bug fixes, security releases, and upgrades, as provided by the distributors of your operating system. Note that you can specify package names with the update command.
• yum upgrade – Upgrades all packages installed in your system to the latest release.