RPM Package Manager facts for kids
 |
|
| Original author(s) | Erik Troan, Marc Ewing, Red Hat |
|---|---|
| Developer(s) | Community & Red Hat |
| Initial release | 1997 |
| Stable release |
4.20 / 7 October 2024
|
| Written in | C, Perl |
| Operating system | Linux, Unix-like |
| Available in | 40 languages |
| Type | Package management system |
| License | GPL |
RPM stands for RPM Package Manager. It was originally called Red Hat Package Manager. RPM is a special system that helps computers manage software. It's free to use and its code is open for anyone to see.
The name RPM refers to two things: the special file type, which ends in .rpm
Even though it started with Red Hat Linux, many other Linux versions use RPM today. These include Fedora Linux, openSUSE, and CentOS. RPM has also been adapted for other computer systems like IBM AIX and ArcaOS.
An RPM package can hold many different files. Most RPM files are "binary RPMs." These contain software that is already compiled and ready to run. There are also "source RPMs" (SRPMs). These have the original source code that developers use to build the software. SRPMs usually end with ".src.rpm".
Contents
History of RPM
RPM was first created in 1997. Two people named Erik Troan and Marc Ewing developed it. They built it based on ideas from older software management systems.
One of these older systems was called pmpm
What RPM Can Do
For someone who manages a computer system, using a package manager like RPM is very helpful. It makes installing and updating software much simpler. It also helps keep everything consistent and can even do tasks automatically.
Here are some cool things RPM can do:
- Check for Safety: RPM packages can be checked to make sure they are real and haven't been changed. This uses special digital checks like GPG and MD5.
- Includes Original Code: Source RPMs (SRPMs) include the original source files. This makes it easier to check if everything is correct.
- Small Updates: RPM can use "Delta updates." These are like small patches that only update the parts of the software that have changed. This saves time and internet data.
- Finds What's Needed: RPM can automatically figure out if a software package needs other programs to work. This helps install everything correctly.
How RPM Works Locally
Software packages often come from a specific Linux version, like Red Hat Enterprise Linux. Sometimes, other groups also create RPMs for these systems.
It can sometimes be tricky if different software packages need each other to work. This is called "dependency hell." If this happens, you might need to install all the related packages at the same time.
Online Software Libraries
RPM packages are often stored in central online places called repositories. Think of them as big online libraries for software. Many computer systems have their own local copies of these libraries. They might also have their own collections of useful RPMs.
Helper Programs for RPM
There are several "front-end" programs that make using RPM easier. These programs help you find and install RPMs from online libraries. They also help solve those tricky dependency issues.
Some popular helper programs include:
- yum: Used in Fedora Linux and Red Hat Enterprise Linux.
- DNF: A newer program used in Fedora Linux and Red Hat Enterprise Linux 8.
- Zypper: Used in openSUSE and SUSE Linux Enterprise.
- urpmi: Used in Mandriva Linux and Mageia.
The RPM Database
Behind the scenes, RPM uses a special database. This database is stored on your computer in a folder called /var/lib/rpm
This database tracks every file that changes or is created when you install a package. This way, RPM can easily undo those changes and remove the software later. If the database ever gets damaged, you can fix it using the rpm --rebuilddb
Understanding RPM Packages
Even though the basic RPM format is the same everywhere, how different Linux versions use it can vary.
Package Name and Label
An RPM package comes as a single file. Its name usually follows a specific pattern:
- For source packages:
<name>-<version>-<release>.src.rpm - For ready-to-use programs:
<name>-<version>-<release>.<architecture>.rpm
For example, in libgnomeuimm-2.0-2.0.0_3.i386.rpm
<name>libgnomeuimm<version>2.0<release>2.0.0_3<architecture>i386
Some RPMs have the noarch.rpm
Inside the RPM file, there's also a "package label." This label contains:
- The software's name.
- The software's version (from the original creators).
- The package release (how many times the package has been rebuilt). This often includes a short code for the Linux version it's for, like "fc4" for Fedora Core 4.
- The computer architecture it was built for (like i386, x86_64).
The information in the package label doesn't always have to exactly match the filename.
How Libraries are Packaged
Libraries are special pieces of code that other programs use. They are often distributed in two separate RPM packages for each version.
- One package has the ready-to-use code for running programs.
- The second package has files needed by developers, like "headers." These packages usually have "-devel" added to their name. It's important that the versions of both packages match.
The RPM File Structure
An RPM file is a binary file, meaning it's in a computer-readable format. It has four main parts:
- The Lead: This part identifies the file as an RPM file.
- The Signature: This helps make sure the file hasn't been tampered with and is authentic.
- The Header: This contains important information about the package, like its name, version, and a list of files inside.
- The File Archive: This is where the actual software files are stored. They are usually compressed to save space.
The SPEC File
To create an RPM package, developers use a "spec file." This file ends with ".spec" and acts like a recipe. It tells RPM how to build, install, and clean up a package. It also includes a history of changes. Developers use a tool called `rpmbuild` to create RPM packages from these spec files.
Spec files are usually found inside SRPM files, along with the original source code.
SRPM (Source RPM)
A typical RPM is software that's already compiled and ready to install. But the original source code can also be shared. This is done in an SRPM. An SRPM includes the "SPEC" file and the source code. This allows users to compile the code themselves, and even change it if they want.
Sometimes, a software package only contains scripts that work on any computer. In these cases, the developer might only provide an SRPM, which can still be installed.
NOSRC (No Source)
This is a special type of SRPM. It contains the "SPEC" file and sometimes patches, but it doesn't include the source code. This usually happens because of licensing rules.
Different Versions of RPM
As of 2010, there were two main versions of RPM being developed. One was led by the Fedora Project and Red Hat. The other was led by a different group.
RPM.org Version
The `rpm.org` community made a big update to their code in July 2007. They have continued to release new versions since then. For example, version 4.13 came out in July 2015, and version 4.20 was released in October 2024.
This version of RPM is used by many popular Linux distributions. These include Fedora Linux, Red Hat Enterprise Linux, openSUSE, Mageia, and OpenMandriva Lx.
RPM v5 (No Longer Used Much)
Another version, RPM version 5, was released in May 2007. This version was used by some distributions like Wind River Linux and Rosa Linux for a while. However, many distributions that used RPM v5 have since switched back to the `rpm.org` version. For example, OpenMandriva Lx switched back for its 4.0 release.
Related Topics
- dpkg — Another system for managing software packages, used by Debian Linux.
- List of RPM-based Linux distributions — A list of Linux versions that use RPM.
See also
In Spanish: RPM Package Manager para niños
