
| Design by | Red Hat |
|---|---|
| Latest release | 4.4.2.3 |
| Preview release | 4.5.90 |
| OS | Linux, Unix-like |
| Type | Package management |
| License | GNU General Public License |
| Website | rpm.org |
RPM Package Manager (Red Hat Package Manager, abbreviated RPM) is a package management system.[1] The name RPM refers to two things: a software package file format, and 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 4.
"RPM Package Manager" as it is used today is an example of a recursive acronym.
Contents |
Package managers have many advantages over relying on manual installation such as:
RPM also has a few advantages over other package managers:
RPM has also been criticized for a lack of consistency in package names and content which can make automatic dependency handling difficult. However, this is not a problem inherent in the RPM format, but rather because of differing packaging guidelines among major Linux distributions that use RPM in packaging such as Fedora, 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 Fedora),[2] tools such as urpmi, yum or apt can perform automatic dependency checking.
The default installer for RPM files, aptly named rpm, does not follow dependency information automatically, requiring the user to manually download various RPM-files. Moreover, circular dependencies between mutually dependent RPMs cannot be installed with rpm unless the user is aware that he needs to specify both on the rpm installer's parameter list first. This leads to what is known as 'dependency hell', particularly for packages with many dependencies, each of which has its own large set of dependencies, and so on. For this reason, wrappers around the rpm tool have been created to help ameliorate the problem; urpmi and yum are two such wrappers.
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 (using RPM) installs a package, thus enabling the user (via RPM) to reverse the changes and remove the package later. If the database gets corrupted (which is possible if the RPM client is killed), the index databases can be recreated with the rpm --rebuilddb command.[3]
Every RPM package has a package label, which contains the following pieces of information:
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.:
libgnomeuimm-2.0-2.0.0-3.src.rpm
Additionally, libraries are distributed in two separate packages for each version. One contains the precompiled code, while the second one contains the development files such as headers, static library 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 an interpreted programming language, such as Python programs and shell scripts.
The "recipe" for creating an RPM package is a spec file. Spec files end in the ".spec" suffix 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.
The package is a binary format and consists of four sections:[1]
Several Linux distributions are based on RPM. These include, but are not limited to:
There are several front ends to RPM that resolve dependencies.
The best-known ones are:
As of the 31 May 2007, there are two versions of RPM in development — one led by the Fedora Project and Red Hat, and the other by a separate group led by a previous maintainer of RPM, a former employee of Red Hat. Both projects currently call themselves the "official" version of RPM.
The rpm.org community's RPM is hosted by OSU Open Source Lab, and the majority of content is maintained in the wiki. The maintainer of RPM is Red Hat developer Panu Matilainen. RPM.org issued its first major code revision in July 2007, and the latest version, 4.4.2.3, was released on 1 April 2008. As of September 2008, rpm.org is about to release a new major release 4.6, featuring cleaned up codebase, bugfixes and several new features such as support for large packages. The preliminary release notes of the new version are available on the rpm.org website, and a preview snapshot version can already be seen in action in Fedora 10 alpha and beta releases.
Its version is used by Fedora, Red Hat Enterprise Linux, Novell's OpenSUSE, Mandriva and CentOS. Panu Matilainen is also the current maintainer of apt-rpm.
The RPM maintainer since 1999, Jeff Johnson, continued his development efforts after leaving Red Hat. Johnson combined with the efforts of OpenPKG in May 2007 to produce RPM version 5. This version is used by distributions like PLD and supported by OpenPKG. This code base has also been ported to many platforms, including BSD, Linux, Solaris and Mac OS X Unix flavors, as well as Microsoft Windows via Cygwin. Additionally, the code base was heavily cleaned up, and now can be compiled with all major C compiler suites, including GNU GCC, Sun Studio and Intel C/C++.
Changes and new features include:
|
|||||||||||||||||||||||
|
||||||||||||||
|
||||||||||||||||||||||||||||
Why are we here?
All text is available under the terms of the GNU Free Documentation License
This page is cache of Wikipedia. History