next up previous contents
Next: Automating Nightly Updates Up: The Yum Client Previous: yum.conf   Contents


At last we should have a system on which yum is functional. For systems administrators building their own repositories and hand crafting yum.conf's to access them, it may have been an arduous and long journey (well, not THAT long - one can actually create a directory path, throw some RPMs into it, run yum-arch on it, cut-n-paste a basic yum.conf into existence, and run yum -c yum.conf list on your new "repository" in about five minutes). For system owners who got a pre-configured yum automatically installed on their system ready to run, well, you may have just skipped to this point (but at least glance over all the sections above so you can appreciate all the work the systems administrator who put together your repository base and the yum rpm did for you).

Note Well: If your system's RPM database is inconsistent because of the use of RPMs -force or -nodeps options, or because you've built and installed libraries or programs directly from source (as opposed to source RPMs) then yum may complain, not work correctly, or even ``break'' some installed subsystem as it attempts to update or install a package that you've already installed and configured by hand. Yum works best on a system that has been installed and modified only with RPMs, ideally RPMs built and distributed in a consistent set. As you can see, this bears repeating...

We now proceed to review the basic yum commands and what each one does for you. This section is not exhaustive by any means. Yum is a very powerful tool with a variety of primary actions that can be modified by both command line options and configuration settings in /etc/yum.conf, so to learn its full range of power you will need to read its man page and possibly take a tour of the yum HOWTO. The following should suffice, though, to get you started and may be all you ever need.

All yum commands cause yum to take the following actions:

Yum is very conservative. It will never perform the equivalent of a -force install. It was designed, as noted above, by systems administrators to facilitate the consistent and scalable maintenance of systems, and thus will balk at any action that might cause your system to enter ``package hell'' (a state of package inconsistency). If yum refuses to do something, then the thing it refuses to do is probably a bad idea for most people to think about. If you are skilled enough to know that it is really OK on YOUR system, you are skilled enough to use rpm itself to override yum.

But do you really want to? Perhaps what you really should be doing is rebuilding the RPMs in question, or fixing some apparent conflict instead of ignoring it. In a sense, yum is the ultimate sanity check. If yum is happy, your repository is consistent, your RPM database is consistent, and your system is happy. If yum is not happy, then chances are pretty good that at least some part of your system could break, which would cost you a lot more time to set right than just making everything consistent to start with.

The following is a brief synopsis of the commands:

yum install package1 [package2 package3...]: Yum checks to see if package1 is already installed and is the latest version. If not, it downloads package1 and all its dependency packages (saving them in its cache directory) and installs them.

yum update [package1 package2...: If there is a basic, essential yum command this is it. Without arguments, yum compares each installed package to packages available on the repository list. If a newer package is available in the repository, it downloads it (saving it in the cache directory) and updates the old one. If a list of packages is given, it only checks for updates of those packages (and their dependencies).

Note that RPM updates generally preserve configuration information and restart daemons and so forth, so your system will generally not require a reboot, although updating the kernel is an obvious exception. Kernel updates are a special case and systems administrators will generally set a policy on this in /etc/yum.conf. In any event, yum will not reboot your system even after a kernel update.

yum remove package1 [package2 package3...]: Yum will first check to see if removing the package breaks anything else (that is, if anything else already installed depends on this package). It will then offer to remove the package and all the packages that depend on it. Yum will generally refuse to leave "dangling" packages that won't work anyway because a critical library or component has been removed. Note that running remove with the -y option is probably a really stupid idea for most people, unless they are certain that they know all of the possible side effects.

yum list [ ,available,installed,updates,extras] [package list]: This is one of yum's most useful commands. Run without arguments or a list of packages, yum lists all packages available to be installed on all repositories. Run with a list of packages (which can contain file wildcard globs, e.g. yum list kernel
to list all kernel package) it shows both the installed packages and the available packages that match the expanded list! The installed, available, and updates options show only installed packages, available packages, or packages that will be updated by the next yum update command. Note Well that when run interactively from a shell, wildcard characters need to be escaped from the shell itself or the command will have unexpected consequences.

yum info [ ,available,installed,updates,extras] [package list]: This command extracts the description and summary from all matching packages and prints it out. It takes the same options as list, but provides different information. yum info > /tmp/packages thus provides you with a shopping list in /tmp/packages of every package either already installed on your system or available on its set of repositories! This can be very useful indeed!

The extras option lists all packages that are installed but not available in the repositories. These are packages you may have installed by hand, for example. A good practice is to create a repository for these local RPMs (which can be nothing but a local directory on the system) and add the repository to the yum.conf file for the system, following the recipe above.

yum search keyword: Searches for packages matching the keyword string in the description, summary, packager and package name fields. This is useful for finding a package you do not know by name but know by some word related to it. The keyword string can contain wildcard file globs. Be sure to escape these from the shell as noted above if run interactively.

yum provides [feature|file]: Find package(s) that provide some feature or file. Accepts file wildcard globs, which again should be escaped from the shell if run interactively.

yum clean: Cleans up yum's cache file. On systems with small disks or limited /var resources, the RPMs that yum caches can fill up the disk. Running yum clean periodically can free up the resources, but it can also mean that yum runs more slowly when doing certain things. Clean takes various options: see the man page for details.

yum group[list,install,update]: Yum has recently acquired the ability to perform the list, install, and update functions 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.

There are a few more commands (some of them deprecated) and of course many more options. Also, if you installed an relatively early version of yum (perhaps in order to support an older Linux distribution that you don't wish to upgrade with the latest python and rpm required to support the latest version of yum) some options may be missing! Read the man page of the particular yum version you installed to review all available commands and options.

next up previous contents
Next: Automating Nightly Updates Up: The Yum Client Previous: yum.conf   Contents
Robert G. Brown 2003-12-17