The current command synopsis for yum is:
Usage: yum [options] <update | upgrade | install | info | remove | list |
clean | provides | search | check-update | groupinstall | groupupdate |
grouplist >
Options:
-c [config file] - specify the config file to use
-e [error level] - set the error logging level
-d [debug level] - set the debugging level
-y answer yes to all questions
-t be tolerant about errors in package commands
-R [time in minutes] - set the max amount of time to randomly run in.
-C run from cache only - do not update the cache
--installroot=[path] - set the install root (default '/')
--version - output the version of yum
-h, --help this screen
# yum install package1 [package2 package3...]
Yum checks to see if package1 is already installed and is the latest version. If not, it downloads package1 {\em and all its dependency packages} (saving them in its cache directory) and installs them. Additional packages can be listed on the same command line. The packages can be specified with standard filesystem globs. Some examples:
# yum install jpilot
This will look for the jpilot package (which provides a lovely interface for palm pilots) and install it if it exists on any of the repositories in any of the yum repositories.
# yum install festival\*
This will install all the packages (e.g. festival and festival-devel) required to run the festival speech generation program or write software that does speech synthesis. Note the "\" required to escape the glob "*" character from the shell.
# yum update package1 [package2 package3...]
Yum checks to see if package1 is installed and is the latest version. If not, it downloads package1 {\em and all its dependency packages} (saving them in its cache directory) and re-installs them (effectively upgrading them). Additional packages can be listed on the same command line. The packages can be specified with standard filesystem globs. Some examples:
# yum update
One of the most important and useful of yum commands, in some ways the command for which yum was invented. This command updates all the installed packages on your system to the latest version on your repository set. This enables you to keep your system current and up to date with a simple script, and to update any package(s) at any time should it be necessary.
# yum update jpilot
This will look for the jpilot package (which provides a lovely interface for palm pilots) and install it if it exists on any of the repositories in any of the yum repositories.
# yum update festival\*
This will update all the packages in the festival speech generation suite that happen to be installed on the system. Note the "\" required to escape the glob "*" character from the shell.
One should always exercise care when removing packages. This is because of dependencies - if you remove a package upon which other installed packages depend (to use a shared library, read a configuration file, even invoke a binary) then those packages are left "dangling" and will be left in a partly or completely dysfunctional state. Yum will try to help you avoid possibly devastating side effects associated with package removal, but as is always the case with something like this, it does require that the user think carefully when using it. It is therefore most unwise to use yum non-interactively when removing packages.
Since it is yum's basic design philosophy to never leave the system in an inconsistent/broken state (yum contains no support for
--force-like options) if you ask yum to remove a package, it will insist on also removing all packages that depend on that package. If the package that you are removing is one upon which something like X itself or Apache depends, you may find yourself removing {\em an entire user interface} or {\em your entire webserver} as the package removal process is recursive through all dependencies. In many cases, this will not be what you want.
Let's understand this. In some cases you may have intended to remove only a top-level package and not realized that some other installed package depends on it. Clearly yum is doing you a service in these cases as it will keep you from removing a package that you didn't realize that you actually needed for something else. In other cases you might argue that you are only removing the package to replace it with another that also satisfies the dependence, so why does yum insist on removing all the dangling packages when you're about to reconnect them?
There are several reasons. For one, unless you have worked very hard and fully expanded the interconnected dependency tree and have done extensive testing of all the programs and tools in that tree, you don't know that the package you are dropping in will actually function as a perfect replacement. It is not enough to know that it provides a needed file or program or library -- one has to work through the version dependence of the needed file or program or library, as these can and do change with time. New features are added, old features go away, two programs with the same name that serve the same general purpose take argument lists that differ in some crucial way.
Of course in some cases you are simply removing a package and replacing it with a more recent package with the same name. However, this is what the update command above does for you already as an atomic entity that never leaves the dependencies dangling, and in general you should use it instead, as it is likely to do a far more careful job of resolving the dependencies and ensuring that the updated package will still suffice.
There is one more place where this sort of remove-and-replace activity is likely to occur - when a package is obsoleted by another package. A package is obsoleted when it is removed entirely from an entire distribution/dependency tree and replace by a completely different package (different 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.