Installing Packages with Yum

# 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.

Updating Packages with Yum

# 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.

Deleting Packages with Yum

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.

yum upgrade

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 --force

and 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

lpr

printing 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 upgrade

function
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 Commands

# 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

groupupdate

function is likely to be only
infrequently required, as of course a

yum update

will
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.