Generated by GPT-5-mini| YUM | |
|---|---|
| Name | YUM |
| Developer | Red Hat, Inc., community contributors |
| Initial release | 2003 |
| Programming language | Python (programming language) |
| Operating system | Fedora (operating system), Red Hat Enterprise Linux, CentOS, Scientific Linux |
| Genre | Package manager |
| License | GPL |
YUM is a package-management utility for RPM-based distributions designed to simplify installation, update, and removal of RPM Package Manager packages. Originating in the early 2000s, it became a standard tool on distributions such as Fedora (operating system), Red Hat Enterprise Linux, CentOS, and Scientific Linux, providing dependency resolution, repository management, and plugin extensibility. YUM’s development involved contributors from Red Hat, Inc. and the open-source community and influenced successor systems and related tooling across the Linux ecosystem.
YUM was created to address dependency resolution limitations in early builds of RPM Package Manager tooling and to provide a higher-level command-line interface than the base RPM Package Manager. The project began in the context of efforts around Red Hat, Inc. and the nascent Fedora (operating system) community, alongside contemporaneous projects like apt (software) from Debian and package utilities developed for Slackware. Over time, YUM integrated with system-management projects such as Spacewalk (software) and influenced configuration management systems including Puppet (software), Chef (software), Ansible (software), and Salt (software). Major distributions incorporated YUM into release workflows for Red Hat Enterprise Linux and downstream derivatives like CentOS and Scientific Linux, while activity around YUM spurred research and development that contributed to the design of successor tools like DNF (software). Corporate stewardship by Red Hat, Inc. and participation from communities tied to Fedora and enterprise distributions shaped YUM’s roadmap and ecosystem adoption.
YUM’s architecture is modular, combining core libraries with utilities and a plugin interface. The core comprises modules originally written in Python (programming language), interacting with the RPM Package Manager libraries to query package metadata, perform installs, and handle transactions. Components include the package metadata parser, the dependency resolver, a transaction engine, and a cache layer that stores repository metadata. YUM’s metadata format and repository layout align with repository publishing tools used by projects such as Koji (build system) and Pungi, while repository mirroring and distribution of metadata often utilize services like mirror.centos.org and mirrors coordinated by The Apache Software Foundation-hosted projects. Integration points exist for configuration management backends used by Red Hat Satellite and automated build systems like Jenkins (software).
YUM exposes a command-line interface providing high-level actions: install, update, remove, list, info, and search. Typical operations interact with commands analogous to those in other ecosystems such as apt (software) in Debian-derived systems. Common commands include 'yum install', 'yum update', 'yum remove', 'yum list', and 'yum search', which rely on metadata structures similar to those produced by repodata generators used in openSUSE and other RPM-using projects. Administrators and automated tools often combine YUM commands with orchestration systems like Systemd, cron, and configuration frameworks such as Puppet (software) and Ansible (software) to maintain system state. YUM also supports package groups and patterns, enabling bulk operations for desktop environments associated with projects like KDE and GNOME (desktop environment).
YUM consumes repository metadata from configured repository files, typically located under /etc/yum.repos.d, each pointing to mirrors, base URLs, and metadata checksums. Repository configuration conventions grew in concert with distribution infrastructure operated by organizations such as Red Hat, Inc. and community projects like CentOS Project and Fedora Project. YUM supports priorities, excludes, and proxy settings, and relies on signed metadata to interoperate with GPG key-based signing methods used by projects like OpenPGP-based signing frameworks. Third-party repositories provided by initiatives like EPEL (Extra Packages for Enterprise Linux), RPM Fusion and vendor-specific repositories for Oracle Linux and SUSE-packaged backports extended YUM’s reach in enterprise and community ecosystems.
YUM’s plugin architecture allows extensions to modify resolver behavior, transaction processing, and command outputs. Plugins are implemented in Python (programming language) and have been used to add features such as fastestmirror selection, deltarpms support, and automatic cache management. Community-maintained plugins developed by contributors from projects like EPEL (Extra Packages for Enterprise Linux) and organizations such as Red Hat, Inc. integrated YUM with additional tooling—examples include plugins for spacewalk/satellite integration and reporting hooks for inventory systems like Foreman (software). The plugin system influenced later package managers’ extension models, including the plug-in approaches adopted by DNF (software).
YUM is often compared to other package managers: apt (software) used by Debian and Ubuntu (operating system), zypper from openSUSE, and newer RPM-layer tooling such as DNF (software). Alternatives and complementary tools include the underlying RPM Package Manager, package-build systems like Mock (software), and repository-build pipelines utilizing Koji (build system) and Pungi. In enterprise contexts, system management solutions like Red Hat Satellite, Spacewalk (software), and SUSE Manager present higher-level lifecycle management features that interact with YUM or its successors. YUM’s legacy persists through widespread historical use and the migration path to tools such as DNF (software) in recent distributions.
Category:Package management