RPM Package Manager
|RPM Package Manager
( September 26, 2019 )
|Unix-like systems such as GNU / Linux and OS / 2 / eComStation
|GPL ( Free Software )
The RPM format is part of the Linux Standard Base , meaning R PM P ackage M anager, formerly R ed Hat P ackage M anager.
In the early days of Linux, the .tgz packages were commonplace; automated administration was hardly possible with them. Dependencies were neither resolved nor at least a warning was issued. Users who wanted to install software either had to know enough to resolve these dependencies themselves, or they simply installed all packages, which in turn brought the risk of package conflicts.
Certain approaches to package management existed when the first tools were developed based on the large package management of the established Unix systems of that time - such as SunOS (a forerunner of Solaris ), HP-UX , OSF / 1 , IRIX or Apollo Domain / OS which, however, had only a few functions.
This caused the Linux distributors considerable problems with the support and maintenance of their software at that time, whereupon two competing systems were developed: the Debian package management dpkg for Debian packages , initiated by the Debian project, and RPM by Red Hat .
The aim was to make software packages easier to handle for both the developer and the user. Dependencies should be taken into account and automatically resolved as far as possible. The system should avoid redundancies such as duplicate files or directories, and it should be possible to uninstall software cleanly, taking dependencies into account. It should also be possible to update software easily and to manage configuration files securely.
A function for reversing errors (transactions and rollback) is now just as much a part of RPM as it is in the large package administrations of HP-UX and Solaris, albeit not to the same extent.
The first version of RPM developed for Red Hat Linux 2.0 in 1995 was based on RPP, PMS (developed by Rik Faith for Linux operating systems in the 1990s) and PM; it was written in Perl . RPM was later rewritten in C.
Originally meant RPM R ed Hat P ackage M anagement. The late nineties, the name has been in R PM P ackage M changed anagement. The background was legal aspects. RPM has since been used by many distributors and efforts were made to include RPM in the Linux Standard Base . The company name (company) in the name of the software would at least have made this difficult.
RPM has been used by numerous Linux distributions such as B. SUSE , Mageia or Mandriva Linux taken over. Some Unix systems such as B. IBM AIX or Solaris as well as non- Unixoid systems like Novell Netware used RPM.
Between 1999 and 2006 the further development of the software practically came to a standstill. Jeff Johnson, the main developer of RPM at Red Hat until 1999, developed the software and took care of bug fixes. From this branch RPM5 emerged as a further development of RPM version 4.
In the meantime (1999–2006) the various distributors developed their own patches for RPM to eliminate errors; Johnson's patches were mostly not used.
In December 2006, various distributors under Red Hat and Novell joined forces to form the RPM project and continued to develop RPM with the respective distribution's own patches - still without Johnson's changes.
This now results in two versions of RPM: RPM with patches from the distributors and RPM5, which is called RPM from the "original code base ".
Since most Linux distributions are free software, the advantage of a certain distribution over others consists largely of the convenience of the respective package manager (and the compiled, tested and regularly updated (RPM) package collections of the respective distributor on the Internet ). Exchanging packages between distributors used to be almost impossible. This got easier with RPM, but it is still problematic as the different distributions using RPM often use different versions and / or configurations of system software such as graphics libraries.
For the developer, a package management system such as RPM simplifies the integration of software into the structure specified by the distribution (paths, dependencies, file names, package names). However, the package format itself does not automatically check the contents of a package. The developer determines the structure of the package independently and has to familiarize himself with the particular features of each distribution.
With the introduction of the Linux Standard Base, many disagreements between the distributors were resolved. LSB makes the work of the package builder considerably easier because at least file names and paths are standardized. Provided the package maintainer takes the appropriate care, it is relatively safe to import an RPM from another LSB distributor into any other LSB system.
Package management is system-dependent. Except for different distributors, not all Linux providers have the same package format. Other systems of course bring their own software.
However, since the GNU software is now part of the basic equipment on many other Unix systems (at least the system administrator usually installs it very quickly), RPM was also ported to other systems - especially as part of the OpenPKG project - so that additional Can import software.
In a sense, this is both a step forward and a step backward. So far, system administrators have compiled the software themselves from the sources and then entered it into the system. This step and the work involved are of course not necessary.
However, there is no communication between the package database of RPM and the native package database, and thus duplicate installations are just as little resolved as missing system dependencies across the package systems.
The RPM files are usually cpio archives compressed with gzip or LZMA ( xz ) , but the individual parts can easily be searched for specific information because a header data area in binary format is attached to each package. These header data are not compressed and contain all important information. This makes it easier to quickly search through RPM packages.
Unpacking without installation is possible:
rpm2cpio foo.rpm | cpio -idmv
XML Package Metadata
The RPM specifications also contain the specifications for directories of multiple RPM packages. The packages are saved in a directory which, in addition to the packages, also contains information about the packages themselves in the form of metadata files. If a suitable program then needs information about the software contained in the directory, it is sufficient to download the metadata. The existing packages, their versions, dependencies, architecture, etc. are contained in this data.
Programs that can manage XML package metadata are yum, Yast, Red Carpet, smartpm, and apt-rpm.
Programs that process RPM packets
- rpm - a Linux program that can be called directly from the console.
- Console front ends
- urpm from Mandriva - this will automatically resolve the dependencies during installation.
- up2date from Red Hat
- Yellowdog Updater, Modified (Yum)
- YaST from SuSE - contains a module for the administration of RPMs
- Smart Package Manager - this tool uses existing tools (rpm, dpkg, ...) and can therefore offer a uniform interface on many distributions
- rpm-ostree - Tool from Red Hat's Atomic Host container operating system
- GUI front ends
- Maintaining tools
- Server / repositories
Operating systems that use RPM
- Fedora Project
- Mandriva Linux (uses a fork)
- Oracle Linux
- Red Hat Enterprise Linux
- Sailfish OS
- Scientific Linux
- SUSE Linux Enterprise ( SUSE Linux Enterprise Server )
- dpkg and .deb - the Debian system
- Ebuild and emerge - the choice with Gentoo Linux
- Pacman - Arch Linux package manager
- Project website from rpm.org (English)
- Project website from rpm5.org (English)
- APT-RPM (English)
- Link catalog on RPM at curlie.org (formerly DMOZ )
- RPM E-Book ( Memento from February 25, 2008 in the Internet Archive ) by Thomas Schletter
- rpm5.org .
- rpm.org .
- Red Hat history. Red Hat , accessed October 25, 2013 .
- The Story of RPM on redhat.com, July 8, 2007
- Pro-Linux , News from December 15, 2006
- rpm5.org ( Memento of the original from August 20, 2007 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.
- Poelstra: XZ (LZMA) Payloads in RPM. Fedora Project , August 19, 2009, accessed May 2, 2014 .