RPM Package Manager
From Wikipedia, the free encyclopedia
RPM Package Manager | |
Platform: | Linux, Unix-like |
---|---|
Use: | Package management |
License: | GPL |
Website: | www.rpm.org |
RPM Package Manager (originally Red Hat Package Manager, abbreviated RPM) is a package management system. The name RPM refers to two things: a software package file format, and a free software tool which installs, updates, uninstalls, verifies and queries software packaged in this format. RPM was intended primarily for Linux distributions; the file format RPM is the baseline package format of the Linux Standard Base.
Originally developed by Red Hat for Red Hat Linux, RPM is now used by many Linux distributions. It has also been ported to some other operating systems, such as Novell NetWare (as of version 6.5 SP3) and IBM's AIX as of version 5.
"RPM" as it is used today is an example of a recursive initialism.
Contents |
[edit] The RPM database
Working behind the scenes of the package manager is the RPM database, stored in /var/lib/rpm
. It consists of a single database (Packages
) containing all of the meta information of the installed rpms and multiple databases used for indexing purposes. The database is used to keep track of all files that are changed and created when a user installs a program and thus allows rpm to remove packages. If the database gets corrupted (which happens easily if the RPM client is killed), the index databases can be recreated with the rpm --rebuilddb
command.[1]
[edit] Package label
Every RPM package has a package label, which contains the following pieces of information:
- the software name
- the software version (the version taken from original "upstream" source of the software)
- the package release (the number of times the package has been rebuilt using the same version of the software) this field is also often used for indicating the specific distribution the package is intended for by appending strings like "mdv" (formerly, "mdk") (Mandriva Linux), "fc4" (Fedora Core 4), "rhl9" (Red Hat Linux 9), "suse100" (SUSE Linux 10.0) etc.
- the architecture the package was built for (i386, i686, athlon, ppc, etc.)
RPM file names normally have the following format:
<name>-<version>-<release>.<arch>.rpm
An example:
nano-0.98-2.i386.rpm
A package label is contained within the file and does not necessarily need to match the name of the file. Source code may also be distributed in RPM packages. Such package labels do not have an architecture part and replace it with "src". E.g.:
libgnomeuimm2.0-2.0.0-3.src.rpm
Additionally, libraries are distributed in two separate packages for each version. One containing the precompiled code and one containing the development files such as header files etc. for the library in question. Those packages have "-devel" appended to their name field. Users need to carefully check so that the version of the development package matches that of the binary package, otherwise the library may not work very well.
RPM files with the noarch.rpm extension refer to files which do not depend on a certain computer's architecture. These files usually include graphics and text for another program to use, and sometimes programs written in a higher-level programming language, such as Python programs and shell scripts.
[edit] Advantages and disadvantages of the format
RPM packages have many often-cited advantages over other package management systems:
- They present a uniform way for the user to install programs.
- Uninstalling programs is simple.
- It is popular: the typical rpm repository contains thousands of free applications.
- Non-interactive installation makes it easy to automate.
- Original source archive (e.g. .tar.gz, .tar.bz2) are included in SRPMs, making verification easier.
- Packages can be cryptographically verified with GPG and md5.
- DeltaRPMs, the RPM equivalent of a patch file, can incrementally update RPM-installed software without needing the original package.
RPM has also been criticized for a lack of consistency in package names and content (termed 'dependency hell') which can make automatic dependency handling difficult. However, this is not a problem inherent in the RPM format, but rather a problem of co-ordination amongst major Linux distributions that use RPM in packaging such as Red Hat Linux, SUSE, and Mandriva Linux. When using packages that are from a particular distribution (say Red Hat Linux) or built for a particular distribution (for example Freshrpms for Red Hat Linux[2]), tools such as yum or apt can perform automatic dependency checking. The number of unused dependencies is this format's biggest drawback. Unlike some source RPMs (SRPM), dependencies built into binary RPMs are mandatory. The problem with this is that developers often compile-in everything they think an end-user is likely to need, resulting in unused software, wasted disk space, and potential security vulnerabilities. Mandriva Linux uses the tool urpmi to help with this problem.
[edit] Spec file
The "recipe" for creating an RPM package is a spec file. Spec files end in the ".spec" extension and contain the package name, version, RPM revision number, steps to build, install, and clean a package, and a changelog. Multiple packages can be built from a single RPM spec file, if desired. RPM packages are created from RPM spec files using the rpmbuild tool.
Spec files are usually distributed within SRPM files, which contain the spec file packaged along with the source code.
[edit] Physical package format
The package is a proprietary binary format and consists of four sections:
- The lead identifies the file as an RPM file and contains some obsolete headers.
- The signature which can be used to ensure integrety and/or authenticity
- The header contains meta information including package name, version, architecture, file list, etc...
- A gzipped cpio archive
[edit] Supported Linux distributions
Several Linux distributions support RPM. These include, but are not limited to:
- Fedora Core
- Mandriva Linux and derivatives:
- PS2 Linux
- Red Flag Linux
- Red Hat Enterprise Linux and derivatives:
- SUSE Linux/openSUSE
- ArkLinux
- Yellow Dog Linux
[edit] Frontends
There are several front ends to RPM that resolve dependencies.
The best-known ones are:
- up2date used in Red Hat Enterprise Linux
- yum used in Fedora Core, CentOS, Scientific Linux, and Yellow Dog Linux
- YaST used in SUSE Linux
- urpmi used in Mandriva Linux
- apt-rpm, a port of Debian's Advanced Packaging Tool (APT) whose use is recommended by some Fedora repositories. It is less actively developed but generally uses fewer CPU cycles than the above.
- Smart Package Manager, available for many distributions
[edit] See also
- APT - package management system used by Debian
- Portage - package management system used by Gentoo
- Autopackage - a "complimentary" package management system
[edit] References
- Detailed information on RPM file format
- Foster-Johnson, Eric (2003). Red Hat RPM Guide. ISBN 0-7645-4965-0.
[edit] External links
- Red Hat RPM Guide from the Fedora project.
- Fox, Pennington, Red Hat 2003: Fedora Project Developer's Guide: Chapter 4. Building RPM Packages
- RPM Package Manager homepage
- The story of RPM by Matt Frye in Red Hat Magazine
- RPM Building as a User
- Bailey, Edward C. 2000: Maximum RPM, an outdated but popular rpm reference
- Bailey, Edward C. 2000: Maximum RPM, actualized Maximum RPM edition
- SUSE Package Conventions
- Package File Format - Linux Standards Base
- RPM -- plans, goals, etc. - Fedora announcement about RPM.
- RPM.org's wiki
- The pre-December 2006 RPM site archive - to which several of the links above refer
- [1] - Program for extracting a file for use in windows