Hubbry Logo
RPM Package ManagerRPM Package ManagerMain
Open search
RPM Package Manager
Community hub
RPM Package Manager
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
RPM Package Manager
RPM Package Manager
RPM Package Manager
View on Wikipedia
from Wikipedia

RPM Package Manager (RPM)
Original authorsErik Troan, Marc Ewing,[1] Red Hat
DevelopersCommunity & Red Hat[2][3]
Initial release1997; 28 years ago (1997)[1]
Stable release
6.0.0 Edit this on Wikidata / 22 September 2025
Repository
Written inC, Perl[4]
Operating systemLinux, Unix-like
Available in41 languages[5]
TypePackage management system
LicenseGPL
Websiterpm.org Edit this at Wikidata

RPM (originally Red Hat Package Manager, now a recursive acronym for RPM Package Manager) is a free and open-source package management system.[6] The name RPM refers to the .rpm file format and the package manager program itself. RPM was intended primarily for Linux distributions; the file format is the baseline package format of the Linux Standard Base.

Although it was created for use in Red Hat Linux, RPM is now used in many Linux distributions such as PCLinuxOS, Fedora Linux, AlmaLinux, CentOS, openSUSE, OpenMandriva and Oracle Linux. It has also been ported to some other operating systems, such as Novell NetWare (as of version 6.5 SP3), IBM's AIX (as of version 4),[7] IBM i,[8] and ArcaOS.[9] An RPM package can contain an arbitrary set of files. Most RPM files are "binary RPMs" (or BRPMs) containing the compiled version of some software. There are also "source RPMs" (or SRPMs) containing the source code used to build a binary package. These have an appropriate tag in the file header that distinguishes them from normal (B)RPMs, causing them to be extracted to /usr/src on installation. SRPMs customarily carry the file extension ".src.rpm" (.spm on file systems limited to 3 extension characters, e.g. old DOS FAT).

History

[edit]

RPM was originally written in 1997 by Erik Troan and Marc Ewing,[1] based on pms, rpp, and pm experiences.

pm was written by Rik Faith and Doug Hoffman in May 1995 for Red Hat Software, its design and implementations were influenced greatly by pms, a package management system by Faith and Kevin Martin in the fall of 1993 for the Bogus Linux Distribution. pm preserves the "Pristine Sources + patches" paradigm of pms, while adding features and eliminating arbitrary limitations present in the implementation. pm provides greatly enhanced database support for tracking and verifying installed packages.[4][10][11]

Features

[edit]

For a system administrator performing software installation and maintenance, the use of package management rather than manual building has advantages such as simplicity, consistency and the ability for these processes to be automated and non-interactive. rpm uses Berkeley DB as the backend database although since 4.15 in 2019, it supports building rpm packages without Berkeley DB (–disable-bdb).[12]

Features of RPM include:

  • RPM packages can be cryptographically verified with GPG and MD5
  • Original source archive(s) (e.g. .tar.gz, .tar.bz2) are included in SRPMs, making verification easier
  • Delta update: PatchRPMs and DeltaRPMs, the RPM equivalent of a patch file, can incrementally update RPM-installed software
  • Automatic build-time dependency evaluation.

Local operations

[edit]

Packages may come from within a particular distribution (for example Red Hat Enterprise Linux) or be built for it by other parties (for example RPM Fusion for Fedora Linux).[13] Circular dependencies among mutually dependent RPMs (so-called "dependency hell") can be problematic;[14] in such cases a single installation command needs to specify all the relevant packages.

Repositories

[edit]

RPMs are often collected centrally in one or more repositories on the internet. A site often has its own RPM repositories which may either act as local mirrors of such internet repositories or be locally maintained collections of useful RPMs.

Front ends

[edit]

Several front-ends to RPM ease the process of obtaining and installing RPMs from repositories and help in resolving their dependencies. These include:

Local RPM installation database

[edit]

Working behind the scenes of the package manager is the RPM database, stored in /var/lib/rpm. It uses Berkeley DB as its back-end. It consists of a single database (Packages) containing all of the meta information of the installed RPMs. Multiple databases are created for indexing purposes, replicating data to speed up queries. 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.[17]

Description

[edit]

Whilst the RPM format is the same across different Linux distributions, the detailed conventions and guidelines may vary across them.

Package filename and label

[edit]

An RPM is delivered in a single file, normally with a filename in the format:

<name>-<version>-<release>.src.rpm for source packages, or
<name>-<version>-<release>.<architecture>.rpm for binaries.

For example, in the package filename libgnomeuimm-2.0-2.0.0_3.i386.rpm, the <name> is libgnomeuimm, the <version> is 2.0, the <release> is 2.0.0_3, and the <architecture> is i386. The associated source package would be named libgnomeuimm-2.0-2.0.0_3.src.rpm

RPMs with the noarch.rpm extension do not depend on a particular CPU architecture. For example, these RPMs may contain graphics and text for other programs to use. They may also contain shell scripts or programs written in other interpreted programming languages such as Python.

The RPM contents also include a package label, which contains the following pieces of information:

  • software name
  • software version (the version taken from original upstream source of the software)
  • 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), "mga" (Mageia), "fc4" (Fedora Core 4), "rh9" (Red Hat Linux 9), "suse100" (SUSE Linux 10.0) etc.
  • architecture for which the package was built (i386, i686, x86_64, ppc, etc.)

The package label fields do not need to match the filename.

Library packaging

[edit]

Libraries are distributed in two separate packages for each version. One contains the precompiled code for use at run-time, while the second one contains the related development files such as headers, etc. Those packages have "-devel" appended to their name field. The system administrator should ensure that the versions of the binary and development packages match.

Binary format

[edit]

The format is binary and consists of four sections:[6]

  • The lead, which identifies the file as an RPM file and contains some obsolete headers.
  • The signature, which can be used to ensure integrity and/or authenticity.
  • The header, which contains metadata including package name, version, architecture, file list, etc.
  • A file archive (the payload), which usually is in cpio format, compressed with gzip. The rpm2cpio tool enables retrieval of the cpio file without needing to install the RPM package.[18]
    • The Linux Standard Base requires the use of gzip, but Fedora 30 packages are xz-compressed and Fedora 31 packages might be zstd-compressed.[19] Recent versions of RPM can also use bzip2, lzip,[20] or lzma compression.
    • RPM 5.0 format supports using xar for archiving.

SPEC file

[edit]

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.

SRPM

[edit]

A typical RPM is pre-compiled software ready for direct installation. The corresponding source code can also be distributed. This is done in an SRPM, which also includes the "SPEC" file describing the software and how it is built. The SRPM also allows the user to compile, and perhaps modify, the code itself.

A software package could contain only platform independent scripts. In such a case, the developer could provide only an SRPM, which is still an installable RPM.

NOSRC

[edit]

This is a special version of SRPM. It contains "SPEC" file and optionally patches, but does not include sources (usually because of license).[21]

Forks

[edit]

As of June 2010, 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.

RPM.org

[edit]

The rpm.org community's first major code revision was in July 2007; version 4.8 was released in January 2010, version 4.9 in March 2011, 4.10 in May 2012, 4.11 in January 2013, 4.12 in September 2014 and 4.13 in July 2015.

This version is used by distributions such as Fedora Linux, Red Hat Enterprise Linux and derivatives, openSUSE, SUSE Linux Enterprise, Unity Linux, Mageia,[22] OpenEmbedded, Tizen and OpenMandriva Lx (formerly Mandriva).

RPM v5 (Defunct)

[edit]

Jeff Johnson, the RPM maintainer since 1999, continued development efforts together with participants from several other distributions. RPM version 5 was released in May 2007.

This version was used by distributions such as Wind River Linux (until Wind River Linux 10), Rosa Linux, and OpenMandriva Lx (former Mandriva Linux which switched to rpm5 in 2011[23]) and also by the OpenPKG project which provides packages for other common UNIX-platforms.

OpenMandriva Lx has switched back to rpm.org[24] for 4.0 release.[needs update]

OpenEmbedded, the last major user of RPM5, switched back to rpm.org due to issues in RPM5.[25][26]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

RPM Package Manager

View on Grokipedia
from Grokipedia
The RPM Package Manager (RPM) is a free and open-source command-line package management system designed for building, installing, updating, uninstalling, querying, and verifying software packages on operating systems, particularly distributions. Originally developed as a tool to manage and dependencies, RPM uses a standardized archive format (.rpm files) that includes binary executables, libraries, and metadata for efficient handling of software components. It maintains a local database on the system to track installed packages, their versions, and file locations, enabling dependency resolution and checks to prevent conflicts during operations. RPM originated in 1995 as an internal project at Software, with its first system commit marking the start of development; it was initially named the Package Manager before evolving into a under community governance. The system was created by developers Erik Troan and Marc Ewing to address challenges in software packaging for early distributions, building on prior tools like pms and pm to provide a more robust solution for binary package management. By 1997, RPM had its first public release and quickly became integral to , later expanding beyond proprietary use as the project was released under open-source licenses such as GPL-2.0-or-later. Key milestones include its adoption in the for interoperability and ongoing enhancements, such as support for multiple digital signatures and in recent versions like RPM 6.0.0 (2025). Widely adopted in enterprise and community environments, RPM serves as the foundation for package management in distributions including , , , , and , where it powers tools like DNF and Yum for higher-level interactions. Beyond , RPM has influenced package systems in other OSes and supports both source and binary packages, allowing developers to create distributable archives that preserve pristine while automating builds and installations. Its design emphasizes security through features like GPG signature verification and file checksums, making it a cornerstone for reliable in production systems.

Introduction

Definition and Purpose

The RPM Package Manager (RPM) is a free and open-source package management system and associated designed for distributing, installing, updating, and managing software on and systems. Originally developed for , with its first version committed in 1995, RPM provides a standardized approach to software packaging that promotes consistency across distributions. It serves as a core component in major Linux ecosystems, enabling administrators and users to handle software efficiently through command-line tools. The primary purposes of RPM include managing both binary and source packages to ensure reliable and installation. It supports dependency resolution by tracking required libraries, executables, and other components, automatically resolving conflicts or missing prerequisites during package operations to maintain system stability. Additionally, RPM enforces consistency in by standardizing package contents and behaviors, reducing errors in multi-system environments. Files with the .rpm extension represent individual software packages that encapsulate compiled binaries, libraries, configuration files, and documentation alongside essential metadata such as package name, version, architecture, and installation instructions. This structure also includes executable scripts for pre- and post-installation tasks, allowing packages to perform custom actions like starting services or updating databases. Source RPMs (.srpm) extend this by including original source code and build specifications, facilitating transparency and customization. RPM enables by allowing users to compile identical binaries from source RPMs using the same specifications, ensuring verifiable and consistent software across environments. It also supports system integrity checks through features like against checksums and digital signatures, helping detect tampering or corruption in installed packages. These capabilities collectively enhance and reliability in software management.

Adoption in Linux Distributions

The RPM Package Manager was initially adopted by in 1995 as its primary packaging system, providing a standardized method for distributing software that facilitated easy installation and updates across systems. This foundation extended to subsequent Red Hat projects, including as a community-driven upstream distribution, and enterprise-focused variants like (RHEL), where RPM remains integral via frontends such as DNF for dependency resolution and repository management. RHEL derivatives, including , , and , have similarly embraced RPM to ensure compatibility and long-term support for server and workstation deployments. Beyond ecosystems, RPM gained traction in other distributions for its robust binary format and metadata handling. and utilize RPM packages managed through the zypper frontend, enabling seamless integration with YaST for graphical configuration and supporting both rolling-release and stable branches. , a of Mandriva, employs RPM with tools like URPMI and DNF for package handling, emphasizing user-friendly updates and support in desktop environments. Similarly, leverages RPM via its APT-RPM system, combining Debian-style repository management with RPM's verification features to cater to independent users seeking a lightweight, customizable setup. In enterprise environments, RPM's adoption underscores its emphasis on stability, with RHEL's long support cycles and cryptographic verification ensuring reliable deployments in data centers and infrastructures. Community distributions, in contrast, highlight RPM's flexibility, allowing rapid iteration and custom repositories that appeal to developers and hobbyists without compromising core integrity. As of 2025, RPM-based systems maintain a strong presence in package management, particularly in servers where RHEL commands approximately 43.1% of the enterprise server , driving adoption in hybrid and scenarios. On desktops, RPM distributions like contribute to 's approximately 4% global desktop as of 2025, bolstered by upstream innovations that influence broader ecosystem tools. RPM integrates natively with via Podman, a daemonless tool developed by and installable as an RPM package on RHEL and , enabling secure, rootless container workflows that align with RPM's security model. It also demonstrates compatibility with universal formats like and , allowing hybrid packaging where RPM handles system-level components while delivers sandboxed applications across RPM-based distros such as and RHEL.

History

Origins and Early Development

The RPM Package Manager (RPM) was developed in 1995 by Marc Ewing and Erik Troan, engineers at Red Hat Software, as a solution for managing software packages in the burgeoning ecosystem. This tool emerged from the need to create a more reliable system than existing ad-hoc methods for distributing and installing software on systems, particularly to support the rapid growth of distributions. At the time, was transitioning from academic and hobbyist use to broader adoption, requiring tools that could automate updates, track installations, and resolve dependencies without manual intervention. RPM's design was heavily influenced by earlier package management systems, including PM (developed in 1995 for by Rik Faith and Doug , building on experiences with PMS—a from used for the (AFS) and in the 1993–1994 BOGUS by Faith, , and Kevin Martin)—and rpp, an internal tool for handling software bundles. These predecessors provided foundational ideas like scriptable installations and basic verification but suffered from limitations in scalability and cross-system compatibility, prompting to unify and enhance them into a robust, open framework. The initial version of RPM, version 1.0, debuted in the beta release of 2.0 in late summer 1995, marking the first widespread use of a database-driven in a major . This integration focused on streamlining for users and administrators, with RPM handling binary packages that included metadata for dependencies and file integrity checks. Early was tied closely to Red Hat's efforts to commercialize , but challenges arose from the absence of industry-wide standards, making integration with other emerging distributions difficult and leading to fragmented tooling in the late 1990s.

Key Milestones and Version Evolution

The RPM Package Manager underwent significant evolution following its initial development, with key advancements in version releases that enhanced dependency resolution, scripting capabilities, and backend storage. RPM 3.0 was released in 1999. In 2000, the project was renamed from Red Hat Package Manager to the more neutral RPM Package Manager on January 17, marking a shift toward broader beyond Red Hat ecosystems. This version introduced improvements in payload compression support, such as in subsequent 3.0.x updates, laying groundwork for more efficient package handling. RPM 4.0, released in 2002, represented a major overhaul, adopting a new database format based on to enable better performance and dependency resolution, allowing older and newer RPM versions to coexist during upgrades. This change facilitated more robust handling of package interdependencies, reducing conflicts in complex installations. The project had been open-sourced under a dual since 1997, promoting widespread contributions and integration into various distributions. In 2008, RPM 5.0 was released as a led by Jeff Johnson, diverging from the mainline rpm.org development to incorporate features like enhanced and delta RPM support for efficient updates; however, it saw limited adoption and became defunct by the 2010s, with no significant updates after around 2013. Mainline development continued with RPM 4.x series enhancements, including the introduction of Lua scripting integration around 2012 for extensible spec file processing and automation. Later milestones in the 4.x series focused on advanced scripting and storage flexibility. RPM 4.13, released in 2016, added file triggers, enabling packages to execute scripts in response to file installations or removals by other packages, improving post-installation automation like database updates. In 2019, RPM 4.15 introduced an optional backend alongside the traditional , offering a lighter, more modern alternative for the package database to address maintenance concerns with the aging DB library. This transition enhanced portability and reduced dependencies in embedded or minimal environments. A pivotal integration event occurred in 2015, when DNF (Dandified YUM), the next-generation frontend for RPM, became the default package manager in Fedora 22, leveraging RPM's core for dependency solving via the libsolv library and improving overall repository management efficiency. The most recent major milestone is the stable release of RPM 6.0.0 on September 22, 2025, which enforces signature checking by default, supports multiple OpenPGP signatures per package, introduces the RPM v6 file format, and incorporates (PQC) keys for future-proofed security. These updates also streamline build processes through refined plugin APIs and enhancements, boosting efficiency in package creation and verification.

Core Features

Dependency Management

The RPM Package Manager employs a metadata-based system to manage software dependencies, utilizing tags such as Provides, Requires, Obsoletes, and Conflicts within package specifications to enable automatic checking during installation and upgrades. The Provides tag allows a package to declare capabilities it offers, such as specific binaries or libraries (e.g., Provides: /bin/sh), which other packages can require without tying to a particular provider, facilitating virtual dependencies for alternatives like multiple shell implementations. Requires specifies mandatory prerequisites, including other packages or capabilities, ensuring they are present before or alongside the current package's installation. Obsoletes identifies superseded packages, prompting their removal during upgrades to treat the new package as a replacement, while Conflicts prevents co-installation of incompatible packages by blocking if a matching capability exists. Dependency evaluation occurs primarily at runtime during package installation or upgrades, where RPM verifies that all Requires are satisfied against the system's database of installed capabilities; build-time evaluation, however, is managed separately to ensure prerequisites for compilation are met without affecting end-user installations. RPM distinguishes between strong dependencies (Requires, Conflicts, Obsoletes) and weaker ones, such as Recommends (optional forward suggestions) and Suggests (very weak forward hints), which are processed or displayed but not enforced to avoid installation failures. Automatic dependencies, like those generated for shared libraries via sonames, are inferred by RPM tools without explicit tagging, enhancing efficiency for common runtime needs. Versioned dependencies in RPM support precise control using operators like >= or <, formatted as [epoch:]version[-release] (e.g., Requires: perl >= 9:5.00502-3), allowing requirements for minimum or exact versions to maintain compatibility across updates. Virtual provides extend this by enabling abstract capability declarations, such as for interchangeable libraries (e.g., different implementations of a database driver), resolved at runtime without mandating specific package names. During package creation, the rpmbuild tool resolves dependencies by checking build-time Requires against available sources, generating the necessary metadata tags to embed in the resulting RPM file for later runtime use. Core RPM lacks built-in automatic dependency resolution, requiring manual satisfaction of unsatisfied Requires or delegation to higher-level front-ends like YUM or DNF for automated solving across repositories. This design can lead to dependency issues, or "dependency hell," in complex systems with intricate versioning chains or solver limitations, where conflicts arise that prevent straightforward installations.

Package Verification and Security

RPM employs GPG signatures to verify the authenticity of packages, ensuring they originate from trusted sources and have not been altered by unauthorized parties during distribution. This process involves signing the package header and using tools like rpmsign, with verification performed via the rpm --checksig command, which checks against imported public keys in the system's RPM keyring. For integrity, RPM calculates and stores checksums such as , , and SHA256 to detect any corruption or tampering in the package contents, with the rpm -K or --checksig options confirming matches against these digests. These verification mechanisms are implemented directly within the .rpm file structure, where the signature header contains tags like Sigpgp for OpenPGP DSA signatures of the header and payload, and digest tags such as SHA256 for the header itself and the compressed payload, enabling end-to-end checks from download to installation. Since RPM 4.14, SHA256 digests have been mandatory for enhanced security, replacing weaker / where possible, while maintaining backward compatibility. Delta RPMs facilitate secure, bandwidth-efficient updates by generating binary patches (deltas) between an installed package and its newer version, which are then applied using the applydeltarpm utility to reconstruct the full updated package. These deltas inherit the same GPG signing and verification as standard RPMs, ensuring and authenticity before application, thus minimizing exposure during transfers over untrusted networks. To enforce runtime security, RPM supports file capabilities, allowing packages to assign fine-grained privileges to executables via extended attributes (e.g., cap_net_bind_service for binding to privileged ports without full access), specified in SPEC files using the %caps macro or %attr with capability flags, reducing the compared to traditional binaries. Additionally, RPM triggers enable runtime security adjustments by executing custom scripts during package events like installation or upgrades of dependent packages, such as applying SELinux contexts or updating access controls to maintain system policy compliance. RPM has addressed several historical vulnerabilities in package verification and handling, including CVE-2011-3378, a memory corruption flaw in header parsing that could enable denial-of-service or via malformed packages; this was mitigated in version 4.9.1.2 through strengthened validation before checks. Modern RPM versions (4.14 and above) support integration with UEFI Secure Boot by allowing kernel modules and bootloaders packaged as RPMs to be signed with certificates, enabling their verification and loading on Secure Boot-enabled systems after enrolling the distributor's public key in the firmware's trusted database.

Package Format and Components

Binary RPM Structure

The binary RPM file follows a structured layout consisting of four primary components: the lead, signature, header, and payload. The lead is a fixed 96-byte section at the beginning of the file that identifies it as an RPM package. It starts with the magic bytes 0xED 0xAB 0xEE 0xDB, followed by the major and minor version numbers (typically 4.0 for modern formats), a package type indicator (0x00 for binary packages), architecture and OS identifiers, a reserved name field, and additional reserved bytes. This section ensures basic file recognition and provides initial metadata redundancy. The follows the lead and contains cryptographic elements for verifying the package's and authenticity. It is structured as a header-like region with tags such as HEADERSIGNATURES (tag 62) indicating the presence of signatures, along with hash values like (tag 1004), (tag 269), and SHA256 (tag 272) for the header and payload. Signature types include public key methods like RSA (tag 268), DSA (tag 267), and PGP variants, with the data padded to multiples of 8 bytes. In binary RPMs, this section authenticates the compiled content without altering the payload itself. The header, immediately after the signature, stores the package's metadata in a flexible tag-value format divided into immutable and mutable regions. The immutable section (tagged with RPMTAG_HEADERIMMUTABLE, tag 63) contains core attributes like name (tag 1000), version (tag 1001), release (tag 1002), (tag 1003), and build time (tag 1006), using data types such as strings, integers, or arrays. The mutable section allows for less critical data, such as file lists or dependencies. Tags are indexed with 16-byte entries specifying the tag number, type, offset, and count, enabling efficient parsing; over 60 tags are defined, with binary RPM headers emphasizing details on compiled binaries and libraries rather than . This structure supports larger headers in later versions through 64-bit indexing. The payload forms the bulk of the binary RPM, comprising a compressed archive of the installed files using the cpio format (SVR4 with CRC). It includes compiled executables, libraries, documentation, and configuration files, distinguished from source RPMs by containing pre-built binaries optimized for the target architecture rather than raw source tarballs and patches. Compression algorithms include gzip (default, with magic bytes 0x1F 0x8B), bzip2, xz, and lzma, configurable via build macros; the archive lists files with permissions, ownership, and timestamps. Scriptlets—executable scripts for pre-install, post-install, pre-uninstall, and post-uninstall actions—are embedded as special cpio entries, allowing runtime behaviors like user creation or service starts specific to binary deployment. The RPM binary format has evolved significantly from version 3 to 6 to address limitations in size, security, and compatibility. Version 3 (circa 1997) used a simpler 96-byte lead and basic MD5 signatures, with headers limited to 16-bit indices and no support for payloads over 4 GB. Version 4 (introduced around 2002) added immutable header regions, header-only signatures, compressed file paths for efficiency, and 64-bit integer support (from 4.6), enabling larger packages and better verification. Further enhancements in 4.12 allowed payloads exceeding 4 GB via extended cpio magic (07070X), while 4.14 mandated SHA256 for stronger hashes. RPM 6.0 (released September 2025) introduces the v6 format with full 64-bit limits, drops legacy MD5/SHA1 support, adds SHA3-256 digests and per-file MIME types, supports multiple OpenPGP v6 signatures and post-quantum cryptography, and uses UTF-8 encoding with a new payload format featuring hex file indices for unlimited sizes—all while maintaining backward compatibility for querying and unpacking with RPM 4.x tools. These changes enhance security and scalability for modern binary distributions without breaking existing ecosystems.

Source RPMs and SPEC Files

Source RPMs (SRPMs) are RPM packages with the file extension .src.rpm that contain the original tarballs, any applied patches, and a SPEC file, enabling of binary RPMs from source. These packages preserve the exact sources used for a given binary RPM version, facilitating , auditing, and adaptation across different architectures or environments. The SPEC file, typically named with a .spec extension, serves as the build recipe within an SRPM, providing instructions for the rpmbuild tool to construct binary packages. It consists of two main parts: the preamble and the body. The preamble contains metadata tags such as Name (the package base name), Version (upstream version number), Release (packager's release count), Summary (brief description), License (software license), URL (upstream project site), Source0 (primary source archive URL or path), Patch0 (first patch file), BuildRequires (build-time dependencies), and Requires (runtime dependencies). For example:

Name: example-package Version: 1.0 Release: 1%{?dist} Summary: An example package License: GPLv2+ URL: https://example.com Source0: https://example.com/releases/%{name}-%{version}.tar.gz BuildRequires: gcc Requires: bash

Name: example-package Version: 1.0 Release: 1%{?dist} Summary: An example package License: GPLv2+ URL: https://example.com Source0: https://example.com/releases/%{name}-%{version}.tar.gz BuildRequires: gcc Requires: bash

The body follows the preamble and includes tagged sections like %description for a detailed package overview, %prep for unpacking sources and applying patches (e.g., using %autosetup or %patch0), %build for compiling the software (e.g., %make_build), %install for placing built files into a temporary build root (e.g., %make_install), %files for specifying which files to include in the final package with attributes like %attr(755, root, root) for permissions, and %changelog for recording version changes in a standardized format such as * Date Packager <email> - Version-Release. SPEC files also employ macros—parameterized text substitutions like %{name} for the package name or %{buildroot} for the installation directory—to enhance portability and readability; these can be defined with %define or %global and evaluated via rpm --eval. The build process begins with preparing the environment using rpmdev-setuptree to create standard directories like SOURCES, SPECS, and SRPMS, followed by placing source tarballs in SOURCES and the SPEC file in SPECS. Invoking rpmbuild -bs <specfile> generates the SRPM from the SPEC file, while rpmbuild -bb <specfile> or rpmbuild --rebuild <srpm> produces binary RPMs by executing the SPEC sections sequentially: unpacking in %prep, compiling in %build, installing in %install, and in %files. This process ensures automated, repeatable package creation, with options like --short-circuit to test specific stages. NOSRC packages, identifiable by the .nosrc.rpm extension, are a variant of SRPMs that omit source code tarballs, relying instead on patches, generated content during the build, or external sources for cases like or documentation-only distributions. They are created when dynamic build dependencies are unresolved (e.g., via %generate_buildrequires), producing a package with BuildRequires metadata but no sources to resolve missing tools. Directives like NoSource: <filename> in the SPEC file exclude specific files from the SRPM payload. The use of SRPMs and SPEC files offers key advantages, including the ability to audit package builds for and compliance by inspecting sources and instructions, perform custom recompilations with modified patches or flags, and distribute build recipes independently of binaries to support community contributions or architecture-specific adaptations.

Package Naming and Metadata

RPM packages follow a standardized convention to ensure clarity and consistency in distribution and management. The typical format is name-version-release.architecture.rpm, where name is the base package identifier, version represents the upstream software version, release indicates the distributor's release number (often including a distribution tag like .el7 for Enterprise Linux 7), and architecture specifies the target platform such as x86_64 or noarch for architecture-independent packages. For example, bash-5.1-3.x86_64.rpm denotes the Bash shell package at version 5.1, third release, for 64-bit x86 systems. To handle complex version precedence, RPM uses an optional epoch field, forming a full version label of name-epoch:version-release. The epoch, an integer typically starting at 0 if omitted, takes priority in comparisons; a higher epoch overrides even newer version-release combinations, allowing distributors to enforce ordering for rebuilt or forked packages. Key metadata tags embedded in the RPM header provide essential information for package handling and user reference. These include Name (the package base name), Version (upstream version string), Release (distributor release), Epoch (version precedence integer), Summary (a concise one-line description of the package's purpose), Description (a detailed multiline explanation), License (the software's licensing terms, such as GPLv3+), Group (a categorization like "Applications/System"), Requires (runtime dependencies as a string array), Provides (capabilities or virtual names supplied by the package), BuildTime (Unix timestamp of the build), and Vendor (contact details for the packager or organization). These tags, stored in the binary header, enable tools to query and resolve package attributes without extracting contents. For shared libraries, RPM packaging emphasizes soname handling to maintain ABI compatibility. The soname (shared object name), embedded during compilation with flags like -Wl,-soname,libexample.so.1, identifies the library's major version for dynamic linking; tools like objdump verify it post-build. Runtime dependencies automatically include sonames via Requires, while development files (headers, pkg-config data, and unversioned symlinks like libexample.so) are separated into -devel subpackages to minimize base package size and avoid unnecessary installations. The -devel package requires the exact version of the base library package for consistency. Best practices for RPM naming and metadata focus on uniqueness and usability to prevent conflicts and support diverse environments. Package names should use lowercase letters and dashes (e.g., httpd-tools instead of httpd_tools) to align with filesystem conventions and avoid overlaps. Metadata like Summary and Description supports internationalization through i18nstring tags, allowing locale-specific translations via tools like %find_lang in build processes. To avoid conflicts, explicit file listings in SPEC files (rather than globs) ensure precise ownership, and unique Provides declarations help resolve virtual dependencies across packages.

Database and Local Operations

Installation Database

The RPM installation database serves as the central local record of all software packages installed on a , enabling queries, verifications, and dependency tracking without relying on external repositories. Located in the /var/lib/rpm/ directory, it maintains an on-disk structure that catalogs package metadata and file associations to ensure integrity and facilitate management operations. The database employs either as the default backend—introduced in RPM 4.16 with 33 in 2020 for improved maintainability and crash recovery—or the legacy format, depending on the distribution and configuration. Since RPM 4.16.0, an additional native database (ndb) backend is also available as a modern alternative to and for enhanced stability. Its core contents include package headers storing essential metadata such as name, version, release, , and summary; comprehensive file lists that enumerate every installed file with attributes like paths, sizes, permissions, and checksums; capabilities defining inter-package relationships through provides, requires, conflicts, and obsoletes tags for dependency resolution; and transaction via install transaction IDs (Installtid) that log sequences of installations, upgrades, and removals. Key operations interact directly with this database: the rpm --query (or rpm -q) command retrieves details on installed packages, supporting formats like --list for file listings, --provides for capabilities, or --changelog for version history, allowing targeted searches such as rpm -q --whatprovides /path/to/file. For integrity checks, rpm --verify (or rpm -V) scans files against database records, flagging discrepancies in checksums, modes, or ownership, with options like --nofiles to focus on package-level verification or -a for all packages. Maintenance tasks include rpm --rebuilddb, which reconstructs indices from stored headers to repair corruption, often invoked as rpm --rebuilddb -v for verbose output during recovery. When handling upgrades or removals, the database dynamically updates entries: upgrades overwrite old headers and adjust file lists while preserving transaction continuity, and removals erase records to prevent orphaned references, all within atomic transactions to maintain consistency. Backups are achieved by the entire /var/lib/rpm/ directory prior to changes, or using backend-specific tools such as db_dump for files or sqlite3 rpmdb.sqlite .dump for to export the schema and data. In environments with large-scale deployments—such as servers managing thousands of packages—the database can encounter scalability challenges, including extended rebuild durations on systems with a large number of entries and query slowdowns due to index fragmentation, exacerbated by the unmaintained Berkeley DB's concurrency limitations. Optimization strategies include regular vacuuming for (sqlite3 rpmdb.sqlite VACUUM), pre-compiling SQL statements in custom tools for repeated queries, and monitoring lock contention via rpmdb_stat; the migration enhances overall robustness but may require tuning for high-concurrency writes in enterprise settings.

Repository Handling

In RPM-based systems, repositories are configured through INI-style .repo files, typically located in the /etc/yum.repos.d/ directory (or equivalent for other front-ends like Zypper), by higher-level package managers such as DNF and Yum that use the RPM database for local operations. These files specify essential parameters such as the baseurl (a direct to the repository) or mirrorlist (a listing multiple mirror servers), along with gpgkey (the or path to the repository's GPG public key for verification), and other options like enabled=1 to activate the repository and gpgcheck=1 to enforce metadata and package validation. The core of a repository's structure lies in its repodata directory, which contains compressed XML files generated to describe available packages without requiring individual downloads. Key files include primary.xml.gz, which provides package metadata such as names, versions, summaries, and dependencies; filelists.xml.gz, detailing the files contained within each package; and otherrepodata.xml.gz for supplementary information like changelogs. This metadata format, known as repomd, enables efficient querying and dependency resolution by client tools. On the server side, tools like createrepo_c generate and update this repodata from a directory of RPM packages, ensuring synchronization between package additions or changes and the metadata index. Clients such as DNF or YUM cache this metadata locally in /var/cache/dnf or /var/cache/yum after downloading it, with synchronization achieved via commands like dnf makecache to refresh expired or outdated caches, preventing stale data during operations. The update process involves the parsing repository metadata to compare available package versions—using epoch, version, and release (EVR) tuples—against those in the local RPM database, identifying and queuing downloads for newer or updated packages. Where supported, such as in older releases, delta RPMs (drpms) allow downloading only the differences between old and new package versions to reduce bandwidth, though this feature has been deprecated in recent distributions due to maintenance overhead. For systems with multiple repositories, mirror lists in .repo files provide redundancy by allowing clients to select from a list of synchronized servers, often using files for automatic fastest-mirror selection or random . Priority handling, configurable via the built-in DNF priorities or the yum-plugin-priorities, assigns numerical values (lower numbers indicating higher priority) to repositories, ensuring packages from preferred sources are chosen first and preventing conflicts from lower-priority mirrors. Security in repository handling emphasizes for encrypted transport, enforced by setting baseurl to https:// and enabling sslverify=1 in .repo files or global configuration to validate server certificates. GPG keys for trusted repositories are imported using rpm --import followed by the key URL or file, allowing verification of signed metadata and packages to detect tampering; repositories without valid keys prompt users during initial access.

Tools and Interfaces

Command-Line Operations

The RPM command-line tool provides essential operations for managing packages on systems using the RPM Package Manager, including installation, upgrading, removal, querying, verification, and building from specifications. These operations are performed directly via the rpm and rpmbuild executables, allowing precise control over package handling without higher-level abstractions. Installation of a new package is achieved using the -i or --install option, which places the package contents into the filesystem and updates the local database; for example, rpm -i example-package.rpm installs the specified file. Upgrading or replacing an existing package employs the -U or --upgrade option, which removes any prior versions before installing the new one, as in rpm -U example-package.rpm. Freshening, via -F or --freshen, upgrades only if an older version is already present. Erasure removes an installed package with -e or --erase, such as rpm -e example-package, and supports options like --nodeps to bypass dependency checks or --test to simulate the action without changes. These modes also accept --justdb to update only the database entry, useful for repairs. Query operations begin with -q or --query to inspect installed packages or files. Listing installed packages uses rpm -q package-name, while detailed information like version, description, and dependencies is retrieved via rpm -qi package-name. File listings within a package are obtained with rpm -ql package-name, and ownership of a specific file is determined by rpm -qf /path/to/file. Additional query formats include --changelog for and --provides for capabilities offered by the package. These queries interact with the underlying installation database for accurate results. Building packages from a SPEC file utilizes the rpmbuild command, which executes defined stages such as %prep (unpacking sources and applying patches), %build (compiling), %install (placing files into a build root), %check (running tests), and %files (assembling the archive). The -bb or binary build mode produces only the binary RPM, as in rpmbuild -bb example.spec, while -ba generates both source and binary RPMs. Options like --clean remove the temporary build tree after completion, --nodeps skips dependency verification during assembly, and --test (via related checks like -bl for file lists) simulates without execution. Verification ensures package integrity using -V or --verify, which compares installed files against the original metadata for attributes like size, permissions, and checksums; rpm -V package-name targets a specific package, or rpm -Va verifies all. Flags such as --nofiles omit file checks and --nodeps ignores dependencies. Transaction sets enable atomic operations across multiple packages, initiated implicitly in multi-file commands or via scripting with options like --test for dry runs, facilitating safe integration into automation scripts.

Front-End Managers

Front-end managers for the RPM Package Manager provide abstracted interfaces that simplify package installation, updates, and maintenance by handling complexities such as dependency resolution and repository interactions, which are not natively addressed by the core RPM tools. These tools, available in both command-line and graphical forms, are integral to major RPM-based distributions, enabling users to manage software without direct manipulation of individual RPM files or databases. Among command-line front-ends, YUM (Yellowdog Updater, Modified) served as a foundational tool for Red Hat-based systems, offering capabilities like automatic dependency resolution and repository querying to streamline RPM operations. However, YUM has been deprecated in favor of DNF (Dandified YUM), which was introduced in Fedora 18 in 2013 and became the default package manager in Fedora 22 in 2015, later adopting it as the primary tool in 8 released in 2019. A further evolution, DNF 5, was introduced in Fedora 41 in 2024, offering enhanced performance, lower resource usage, and improved dependency resolution as of 2025. DNF improves upon YUM with enhanced performance, including support for parallel downloads via repositories, more accurate dependency solving using SAT solvers, and better handling of modular content streams introduced in RHEL 8 for versioned application suites. For and distributions, Zypper acts as the primary command-line front-end, leveraging the libzypp library to perform dependency resolution, repository management, and package searches across multiple sources. Zypper supports features like enabling or disabling repositories on-the-fly and pattern-based installations for grouped software sets, making it suitable for both scripted and interactive use in enterprise environments. In , a community-driven derivative of , the urpmi front-end provides similar functionality, including automatic dependency handling and media source integration for RPM packages from local or remote repositories. Graphical front-ends further enhance accessibility for desktop users. GNOME Software, the default tool in -based RPM distributions like and RHEL, integrates with PackageKit to offer a user-friendly interface for searching, installing, and updating RPM packages alongside Flatpaks, with built-in dependency resolution and repository filtering. Discover serves a comparable role in Plasma environments, utilizing PackageKit backends such as DNF or Zypper to enable visual package browsing, reviews, and installations while managing repository states and updates. In SUSE ecosystems, the YaST (Yet another Setup Tool) software management module provides a comprehensive graphical and text-based interface for RPM operations, including dependency-aware installations, repository configuration, and pattern selections for desktop or server profiles. These front-ends share key features that distinguish them from raw RPM commands, such as automatic dependency resolution to prevent conflicts, dynamic repository enabling/disabling for targeted updates, and cross-repository searches to locate packages efficiently. The migration from YUM to DNF, accelerating after 2015 in and extending to RHEL 8 in 2019, reflects a broader trend toward modular packaging integration, allowing front-ends like DNF to manage application streams with multiple compatible versions coexisting on the system. This evolution has improved scalability and across RPM-based distributions.

Variants and Forks

RPM.org Implementation

The RPM.org implementation represents the mainline development branch of the RPM Package Manager, hosted under the rpm-software-management community at rpm.org since and serving as the core package management system for distributions including , (RHEL), and openSUSE. This governance model emphasizes collaborative open-source maintenance, with development coordinated through the organization rpm-software-management, ensuring compatibility and evolution aligned with the needs of these enterprise and community-driven ecosystems. Significant enhancements in this implementation have focused on modernizing the backend and scripting capabilities. The database backend became the default in RPM 4.16 (released in 2020), replacing the older for improved performance and portability in package database operations. Starting with RPM 4.14 in , the macro system underwent a major revamp, introducing more powerful expression handling and conditional logic to streamline spec file authoring and build processes. The community surrounding the RPM.org implementation is vibrant and structured for effective collaboration. Discussions occur via dedicated mailing lists, such as [email protected] for general usage queries and [email protected] for maintainer-specific topics, with announcements distributed through [email protected]. Bug reports and feature requests are managed primarily through the GitHub issue tracker at rpm-software-management/rpm, supplemented by Matrix and IRC channels for real-time interaction. Integration with Fedora's Koji build system exemplifies practical community contributions, where RPM tools facilitate automated package compilation and testing in a distributed environment. Licensing under the RPM.org implementation balances openness with practical reuse: the core tools are distributed under the GPLv2+ license, while key libraries like librpm and rpmio fall under LGPLv2+, allowing broader incorporation into other software projects. As of November 2025, the project maintains active development momentum, highlighted by the RPM 6.0.0 release on September 22, 2025, which prioritized performance optimizations in signature verification and expanded native support for ARM64 architectures to address growing demands in embedded and environments.

RPM5 and Other Derivatives

The RPM5 project emerged as a significant of the RPM Package Manager in 2007, initiated by long-time maintainer Jeff Johnson to incorporate advanced features not prioritized by the mainline rpm.org development led by and . This divergence stemmed primarily from disagreements over feature priorities, including the integration of alternative database backends and scripting enhancements, while the mainline focused on stability with the existing (BDB) backend. RPM5 version 5.0.0 was officially released on January 5, 2008, maintaining full backward compatibility with RPM version 4 package formats to ensure seamless handling of existing binaries and source RPMs (SRPMs). Key innovations in RPM5 included Python bindings for programmatic access to RPM functionality, enabling developers to script package queries, installations, and database interactions directly in Python. It also introduced Lua scripting support for spec files, allowing more dynamic build-time logic, and enhanced SRPM handling, such as improved support for "NOSRC" packages—special SRPMs that exclude source tarballs for proprietary or restricted software while retaining spec files and patches. Additionally, RPM5 explored experimental database backends like ndb (a lightweight alternative to BDB) to address performance issues in large repositories, though adoption remained limited due to compatibility concerns. Mandriva Linux adopted RPM5 starting with its 2011 release, citing benefits like reduced bloat and better multi-architecture support for its international user base. However, the fork faced challenges, including integration issues that disrupted installers and led to further internal forks within Mandriva's ecosystem. By 2018, OpenMandriva Lx—the primary successor to Mandriva—reverted to the rpm.org implementation (RPM4 series) for its 4.0 release, motivated by superior upstream support, fewer bugs, and alignment with tools like DNF. Development on RPM5 effectively stalled after version 5.3.3 in 2010, rendering it defunct by the early 2020s as no major updates occurred and remaining users, such as OpenEmbedded, also migrated back to rpm.org due to unresolved stability issues. Other derivatives include ALT Linux's customized RPM variant, which extends the core with additional metadata tags for integration with its APT-RPM frontend, supporting features like enhanced dependency resolution and build identifiers (e.g., DistTag for repository tracking). These extensions facilitate ALT's branch-based development model across Russian enterprise and embedded environments. Historical RPM4-based forks appeared in older distributions like and early , often to accommodate custom front-ends or kernel-specific packaging, but most converged on rpm.org by the mid-2010s to avoid fragmentation. Overall, the RPM5 and related derivatives highlighted tensions in RPM evolution but ultimately contributed to reduced fragmentation post-2020, as major distributions standardized on the rpm.org version for broader compatibility and active maintenance.

References

  1. https://rpm.org/
  2. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/rpm_packaging_guide/getting-started-with-rpm-packaging
  3. https://docs.fedoraproject.org/en-US/fedora/f40/system-administrators-guide/RPM/
  4. https://rpm.org/about.html
  5. https://github.com/rpm-software-management/rpm
  6. http://rpm5.org/
  7. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/packaging_and_distributing_software/introduction-to-rpm_packaging-and-distributing-software
  8. https://sigs.centos.org/automotive/features-and-concepts/con_rpm-packages-and-the-rpm-package-manager/
  9. https://linux.die.net/man/8/rpm
  10. https://rpm.org/timeline
  11. https://www.redhat.com/en/blog/how-manage-packages
  12. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_software_with_the_dnf_tool/index
  13. https://en.opensuse.org/Portal:Zypper
  14. https://wiki.mageia.org/en/URPMI
  15. http://pclosusers.com/wiki/index.php?title=Packaging_for_PCLinuxOS
  16. https://sqmagazine.co.uk/linux-statistics/
  17. https://gs.statcounter.com/os-market-share/desktop/worldwide/
  18. https://www.redhat.com/en/topics/containers/what-is-podman
  19. https://flatpak.org/
  20. https://www.abortretry.fail/p/the-history-of-red-hat
  21. https://blog.packagecloud.io/red-hat-enterprise-linux-history/
  22. http://rpm5.org/docs/rpm-guide.html
  23. http://ftp.rpm.org/max-rpm/ch-preface.html
  24. https://fedoraproject.org/wiki/History_of_Red_Hat_Linux
  25. https://jfearn.fedorapeople.org/en-US/RPM/4/html/RPM_Guide/ch-rpm-evolution.html
  26. http://rpm5.org/community/rpm-announce/0001.html
  27. https://www.osnews.com/story/19137/rpm-5-a-fork-in-the-linux-packaging/
  28. https://fedoraproject.org/wiki/Features/DNF
  29. https://fedoramagazine.org/managing-packages-fedora-dnf/
  30. https://rpm.org/releases/6.0.0
  31. https://www.phoronix.com/news/RPM-6.0-Released
  32. https://rpm-software-management.github.io/rpm/manual/dependencies.html
  33. https://access.redhat.com/articles/3359321
  34. https://rpm.org/docs/latest/manual/format_v4.html
  35. https://rpm.org/docs/4.19.x/manual/tags.html
  36. https://rpm.org/wiki/Releases/4.14.0
  37. https://github.com/rpm-software-management/deltarpm
  38. https://rpm-software-management.github.io/rpm/manual/triggers.html
  39. https://rpm.org/wiki/Releases/4.9.1.2
  40. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/signing-a-kernel-and-modules-for-secure-boot_managing-monitoring-and-updating-the-kernel
  41. http://ftp.rpm.org/max-rpm/s1-rpm-file-format-rpm-file-format.html
  42. https://rpm-software-management.github.io/rpm/manual/format_v6.html
  43. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/packaging_and_distributing_software/index
  44. https://rpm-packaging-guide.github.io/
  45. https://rpm.org/docs/4.19.x/manual/spec.html
  46. https://rpm.org/docs/6.0.x/man/rpmbuild.1
  47. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html-single/rpm_packaging_guide/index
  48. https://docs.fedoraproject.org/en-US/packaging-guidelines/
  49. https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/
  50. https://docs.fedoraproject.org/en-US/fedora/f36/system-administrators-guide/RPM/
  51. https://access.redhat.com/articles/2581
  52. https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb
  53. https://rpm.org/user_doc/db_recovery.html
  54. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/5/html/deployment_guide/ch-rpm
  55. http://rpm.org/docs/6.0.x/man/rpm.8
  56. https://access.redhat.com/solutions/6903
  57. https://jfearn.fedorapeople.org/en-US/RPM/4/html/RPM_Guide/ch04s05s02.html
  58. https://rpm-devel.rpm5.narkive.com/PwhfQbP6/testing-rpm-5-in-practice-berkeley-db-to-sqlite-migration-with-rebuilddb
  59. https://access.redhat.com/solutions/3330211
  60. https://developers.redhat.com/articles/2022/10/07/whats-inside-rpm-repo-file
  61. https://dnf.readthedocs.io/en/latest/conf_ref.html
  62. https://blog.packagecloud.io/yum-repository-internals/
  63. https://en.opensuse.org/openSUSE:Standards_Rpm_Metadata
  64. https://linux.die.net/man/8/createrepo
  65. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/deployment_guide/sec-yum_repository
  66. https://fedoraproject.org/wiki/Changes/Drop_Delta_RPMs
  67. https://docs.pulpproject.org/en/2.19/plugins/pulp_rpm/tech-reference/rpm.html
  68. https://access.redhat.com/solutions/45244
  69. https://www.redhat.com/en/blog/rpm-gpg-verify-packages
  70. https://rpm.org/docs/6.0.x/man/rpm.8
  71. https://rpm.org/docs/6.0.x/man/rpmbuild.8
  72. https://blog.packagecloud.io/what-is-yum-package-manager/
  73. https://www.linode.com/docs/guides/dnf-package-manager/
  74. https://phoenixnap.com/kb/dnf-vs-yum
  75. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/packaging_and_distributing_software/new-features-in-rhel-8_packaging-and-distributing-software
  76. https://fedoraproject.org/wiki/Changes/BuildWithDNF5
  77. https://documentation.suse.com/smart/systems-management/html/concept-zypper/index.html
  78. https://linuxcommandlibrary.com/man/urpmi
  79. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/administering_the_system_using_the_gnome_desktop_environment/assembly_installing-software-in-gnome_administering-the-system-using-the-gnome-desktop-environment
  80. https://apps.kde.org/discover/
  81. https://documentation.suse.com/sles/15-SP7/html/SLES-all/cha-yast-software.html
  82. https://www.namehero.com/blog/yum-vs-dnf-all-you-need-to-know/
  83. https://developers.redhat.com/articles/2022/10/07/move-apt-dnf-package-management
  84. https://rpm.org/releases/4.16.0
  85. https://rpm.org/releases/4.14.0
  86. https://rpm.org/community.html
  87. https://lwn.net/Articles/236148/
  88. https://www.phoronix.com/news/OpenMandriva-Back-To-RPM4
  89. https://www.osnews.com/story/24686/jeff-johnson-about-to-fork-rpm-again/
  90. http://packages.altlinux.org/en/sisyphus/srpms/rpm/specfiles/
  91. https://lwn.net/Articles/441085/
Add your contribution
Related Hubs
User Avatar
No comments yet.