Yum is a tool for automating package maintenance for a network of workstations running any operating system that use the Red Hat Package Management (RPM) system for distributing packaged tools and applications. It is derived from yup, an automated package updater originally developed for Yellowdog Linux, hence its name: yum is "Yellowdog Updater, Modified".
Yellowdog Linux has gone away at this point, but anyone looking for a version of linux for PowerPC computers can perhaps get help from the list at PC World.
Yup was originally written and maintained by Dan Burcaw, Bryan Stillwell, Stephen Edie, and Troy Bengegerdes of Yellowdog Linux (an RPM-based Linux distribution that runs on Apple Macintoshes of various generation). Yum was originally written by Seth Vidal and Michael Stenner, both at Duke University at the time. Since then both Michael and Seth have moved on, Seth to working for Red Hat, where he remains the dominant force behind yum development and maintenance.
It is important to note that yum is an open source GPL project and that many people have contributed code, ideas, bug fixes and documentation. The AUTHORS list was up to 26 or so as of the time of this HOWTO snapshot; yum is a clear example of the power of open source develpmment!
Yum is a Gnu Public License (GPL) tool; it is freely available and can be used, modified, or redistributed without any fee or royalty provided that the terms of its associated license are followed.
Yum consists of the yum client itself as well as a suite of tools and numerous plugins that modify the basic default behavior of the yum client. In addition, the createrepo command allows one to create a yum repository on any suitable server. Once a yum repository is prepared any client permitted to access the repository over the network can install, update, or remove one or more rpm-based packages from the repository. Yum can also be used as a more or less drop-in replacement for executing the familiar:
rpm -Uvh whatever.rpmcommand, with the benefit that yum will automatically search its connected repositories for dependencies for the RPM at hand and permit them to be automagically installed in one step. This alone is an enormous benefit compared to trying to work one's way out of "dependency hell" and track down and install by hand all of the dependencies of a typical RPM package.
In addition, the yum client encapsulates various informational tools. It can list rpm's both installed and available for installation, extract and publish information from the rpm headers based on keywords or globs, find packages that provide particular files. Yum is therefore of great use to users of a workstation, either private or on a LAN; with yum they can look over the list of available packages to see if there is anything "interesting", search for packages that contain a particular tool or apply to a particular task, and more.
If this isn't enough, yum is the back end for a number of GUI tools that provide a user with "instant" visual access to the entire (rather enormous) range of packages available for any linux distribution that relies on it. For example, in Fedora 12 (as of the current snapshot of this HOWTO) there are over twenty thousand individual packages listed in the repositories connected to my personal laptop. Not all of these are distinct applications as many applications have distinct packages such as the application itself, a development package, a library package and a documentation package, but it is safe to say that there are many thousands of actual applications, most of them well written and maintained and quite useful. A GUI-based tool is a useful way to browse through this list to see what is available that you might find useful or cool to have on your personal linux/yum-based machine.
Yum is designed to be a client-pull tool, permitting package management to be "centralized" to the extent required to ensure security and interoperability even across a broad, decentralized administrative domain. No root privileges are required on the server by yum clients -- yum rquuires at most anonymous access (restricted or unrestricted) from the clients to a repository server (often one that is maintained by a central -- and competent -- authority). This makes yum an espicially attractive tool for providing "centralized" scalable administration of linux systems in a decentralized network management environment, where a mix of machines maintained by their owners and by a variety of network managers naturally occurs (such as a University or corporation).
One of yum's most common uses in any LAN environment is to be run from a nightly cron script on each yum-maintained system to update every rpm package on the system safely to the latest versions available on the repository, including all security or operationally patched updates. If e.g. yum-cron is itself installed from a rpm custom-preconfigured to perform this nightly update, an entire campus that installs its systems from a common repository base can achieve near complete consistency with respect to distribution, revision, and security. Security and other updates will typically appear on all net-connected clients no more than 24 hours after the an updated rpm is placed on the repository by its (trusted) administrator who requires no root-level privileges on any of the clients.
Consequently with yum a single trusterent name, possibly different contents). This happens fairly regularly, if rarely, especially when the obsoleted package provides a configuration file that is shared by several tools. RPM's obsoletion process is very tricky, and can break things even when used correctly as it depends on all the packages in the dependency tree doing the right thing. Package are often obsoleted when a distribution changes its revision number, as that is the right time to manipulate entire branches of the tree with minimal impact.
The yum upgrade command listed below is the solution to the problem of obsoletion. It functions much like update, except that it manages the RPM obsoletes.
In any event, the command syntax for package removal is:
# yum remove package1 [package2 package3...]
As noted above, it removes package1 and all packages in the dependency tree that depend on package1, possibly irreversibly as far as configuration data is concerned. Be certain that the list of removed packages that it generates meets with your approval before proceeding. Additional packages can be listed on the same command line, and the packages can be specified with standard filesystem globs although this makes the problem of certifying the list it generates for removal even more difficult.
Upgrading is the same as updating (and takes similar arguments) except that, as noted above, it also resolves and manages RPM package obsoletes, which remove core packages upon which many things depend and replace them (and as many of the dangling dependencies as possible) with a new, consistent branch in the dependency tree. This is not a completely safe thing to do in many cases because the overall replacement process can be very wide-reaching and have side effects that are difficult to fully explore in a testing process.
Note that under ordinary circumstances one should almost never encounter obsoletes unless you are actually upgrading from one distribution revision to another or are mixing packages from two different distributions revisions into your repository. For a variety of reasons, the latter is a really bad idea unless you love administrative pain. For a variety of reasons, it is often done anyway, and one of the things that tempts the use of
rpm --forceand consequently "breaks" the RPM database so that it becomes nearly impossible to safely resolve dependencies in the future. Yum upgrade at least gives you your best chance not to egregiously break something in this process without fair warning.
Even the legitimate purpose of doing a full revision upgrade is fraught with peril. For example, in revision upgrades the entire format of key configuration files in /etc might well change, and all tools and functions that depend on them might also need to change all the way down at the API or ABI level. It is again difficult to know that the RPMs for the entire upgraded tree are sufficiently carefully built that they can manage to both remove the old configuration files and preserve their contents and port the contents into the newly supported format, if possible. It is not at all unlikely that configuration data may be lost across an upgrade and that a system will therefore require a certain judicious amount of reconfiguration afterwards to regain full functionality.
For a specific example of this, consider the gradual replacement of the old Unix
lprprinting system with the newer
CUPS(Common Unix Printing System). Every aspect of printing configuration changes between the two, and it is nearly impossible to upgrade from one to the other without totally redoing the way printing is managed.
Because of these issues and yum's desire to function and do no harm in the process, it is likely the the
yum upgradefunction will be deprecated in the not horribly distant future. For that reason it is listed last in this HOWTO. In the meantime, it can certainly be a useful command and yum often does extraordinarily well at doing an upgrade, for all the dire warnings above. The author (rgb) of this HOWTO has used yum to upgrade Red Hat based systems on several occasions with complete satisfaction. He no longer does this - better practice is to develop e.g. a kickstart description of the systems in question that permits a full (re)install at any time into a perfectly functional state. This kickstart file is a much safer basis for upgrading the system to new distributions as they are released, as a full install eliminates the obsolescence process altogether, or at least forces one to confront precisely the relevant configuration issues as the emerge.
# yum group[install,update] group1 [group2 group3]
Yum has recently acquired the ability to perform the install, and update functions (as well as the list function, defined below) on package groups defined for a system, with otherwise similar arguments. This makes it relatively easy to install an entire block of software all at once, on systems that have package groups defined.
This can be very useful if one is using yum as a full scale system installation tool in its own right. For example, it is possible to put X onto a server originally installed without it by means of:
# yum groupinstall "X Window System" "X Software Development"
The
groupupdatefunction is likely to be only infrequently required, as of course a
yum updatewill update all packages on the system whether or not they were originally installed as a part of a group. One could imagine, perhaps, a circumstance where one wishes to update a particular group to current but not update the rest of your software installation to current, but I (rgb) have never encountered one.