Yum

The yum (Yellowdog Updater, Modified) tool was a rewrite of another tool called yup (Yellowdog UPdater). It’s just an RPM-based package manager, good for installing and removing software (including dependencies) from one’s system in a safe, easy manner. People liked it, it eventually just became “the thing to use” on RPM-based systems (such as Fedora and family, Yellow Dog itself, and tons others).

Their homepage is at yum.baseurl.org.

Repositories

To function, Yum relies on repositories (‘repos’ for short) which are locations online that store RPM packages. When one specifies a particular package to install, Yum looks through a list of repos for what was specified, then downloads and installs it (if available in one of the repos), along with any other programs it may depend on.

On a given system, repo specifications are stored at /etc/yum.repos.d/*.repo. These vary according to whatever the admin defines or whatever a distro has set up as default. The .repo files are just short config files that may contain something from this non-exhaustive list:

  • id, a machine-readable name of the repo in [brackets], used when needing to specify a repo in a script
  • name=, human-readable name of the repo
  • baseurl=, a URL to the repository/directory
  • enabled=, boolean value (1 or 0), determines whether yum will try to use this repo or no
  • gpgcheck=, boolean value, specify whether GPG signature checking should take place
  • gpgkey=, URL to the gpg key
  • exclude=, list of packages to exclude
  • includepkgs=, list of packages to include

The first 4 (id, name, baseurl and enabled) are required, the others are optional. Here’s an example entry in a .repo file:

[remi-safe]
name=Safe Remi's RPM repository for Enterprise Linux 7 - $basearch
#baseurl=http://rpms.remirepo.net/enterprise/7/safe/$basearch/
#mirrorlist=https://rpms.remirepo.net/enterprise/7/safe/httpsmirror
mirrorlist=http://rpms.remirepo.net/enterprise/7/safe/mirror
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-remi

Note that one single .repo file may contain specs for multiple repositories. The above was one entry of two.

You can get a quick list of which repos are on your system and some detail about them by running yum repoinfo.

Installing New Repositories

You could create a .repo file manually, but typically repo mantainers will provide something such as this line from RPM Fusion:

sudo yum localinstall --nogpgcheck https://download1.rpmfusion.org/free/el/rpmfusion-free-release-7.noarch.rpm https://download1.rpmfusion.org/nonfree/el/rpmfusion-nonfree-release-7.noarch.rpm

So you can just use yum to install a new repo. Convenient. I imagine sudo rpm -i rpmfusion-free-release-7.noarch.rpm would also do the trick.

Install And Update Packages

Yum’s bread and butter is installing software. All you’d need to do is this:

yum install foo

Then it would install the foo package. The magic comes in though when foo has dependencies (relies on other packages to function). Yum will automatically recognize which packages are required and install them (if they’re not already present on the system).

Upgrading is about the same. One can upgrade individually:

yum upgrade foo

or

yum upgrade

In the first case, only foo is updated, as well as its dependencies. In the latter case, all packages across the system are updated to the latest version available in the repositories.

Many options are available here though, including “upgrading” to an older version, etc. Check the man for info.

Remove Packages

Dependency resolution goes both ways, and when using yum remove foo, by default yum will remove any packages that may depend on foo (since they won’t work anymore and would only be taking up space is my guess). Here’s a theoretical “tree” of packages that happen to be installed on a system:

A
|-B
|-C
D
|-E
  |-F

B and C depend on A. F depends on E which in turn depends on D.

yum remove B would result in:

A
|-C
D
|-E
  |-F

Notice that B is the only thing that’s gone.

yum remove E would result in:

A
|-B
|-C
D

There’s a cool thing called autoremove that utilizes a special config option which will remove a package, any packages that depend on it, but also packages that were only there because what you removed depended on them (but nothing else).

yum autoremove B would still result in:

A
|-C
D
|-E
  |-F

But yum autoremove E would be a bit different:

A
|-B
|-C

That’s because D was only there because E depended on it. So it was removed! Cool! That’s one tool for fighting against needless bloat on a system.

It’s also possible to yum autoremove (without specifying a package) and it’ll just remove any of those packages that were only installed automatically to resolve some dependency. Those packages are known as ’leaf’ packages. Note it won’t remove anything that was explicitly installed by the user, only those that Yum calculated were needed.

Groups

Groups in yum are just regular packages that are set to “require” other packages. Yum has a yum groups command which has subcommands such as group install or group remove that can allow one to act on groups. Essentially all we have to do here is specify a group to install or remove or whatever just like we do for individual packages:

yum groupinstall foo

You can see a list of groups by doing:

yum grouplist -v

The -v helps because it gives the id of each group as well as a human readable name. That ID can be used to:

yum groupinfo <id>

Database

Yum maintains its own database under /var/cache/yum/ which apparently stores info beyond what’s in the RPM database (though they asked a couple of times if they could just store this info inside of the RPM database but never got a green light). It isn’t actually a database though, but a flat file structure. It’s supposedly there for making life with Yum a bit nicer for the user, but isn’t apparently necessary for proper functionality. The following is from their yumdb page:

So here’s a list of all the items that should be set for every package (from yumdb info) from 3.2.29 onwards:

  • from_repo: the name of the repo from which the pkg was installed
  • from_repo_revision: Repo. revision. Or ctime for a local package.
  • from_repo_timestamp: Repo. timestamp. Or mtime for a local package.
  • reason: reason for installing this pkg (user, dep, etc) releasever: $releasever of the system at the time the pkg was installed (so you can look for pkgs which have * > lingered across release updates) installed_by (3.2.28): The loginuid of the user who first installed this package (note that some tools which call yum don’t obey loginuid, this not being set is one of many problems that introduces). This doesn’t cross > * Obsoletes.
  • changed_by (3.2.28): The loginuid of the user who last installed this package.

These are known other keys:

  • checksum_type: The type of the checksum for the installed pkg. Eg. md5, sha1, sha256.
  • checksum_data: The value of the checksum for the installed pkg.
  • origin_url (3.2.29): Requires a newer urlgrabber, this is the url that the package was download from. command_line: The command line used to install this pkg (only set if pkg. installed from a tool that has a * > command line).
  • installonly: Not set by yum, but looked at to see if installonly packages should be automatically removed.
  • group_member (3.2.29+?): Set by yum if a package was installed as part of a “group install” (beta patch).

One can manipulate the yumdb by using the yumdb command. You can add notes, whatever. Very basic usage is just getting info for a package such as yumdb info foo. For more command options check man yumdb.

Honestly, to me this sounds like regular ol’ metadata that should just be a part of the regular cache (see next section). As far as I can tell though, it’s separate. I don’t know why it’s separate. Maybe someday I will.

Cache

Yum stores a cache at /var/cache/yum/ of pretty much anything that can be retrieved from a remote repository. According to the man page, these items are all considered part of Yum’s cache:

  • expiration time (expire-cache) - when the data for a particular repository is considered out of date and should be refreshed
  • packages - full .rpm packages downloaded from repositories
  • headers - something old versions of Yum used for dependency resolution
  • metadata - files which yum uses to determine the remote availability of packages
  • dbcache - an sqlite db used for faster access to metadata (so there are flat files AND a db?? That sounds efficient)
  • plugins - each plugin may or may not cache info

One can clear the cache by simply using yum clean bar where bar could be one of the above specific items, or just use all to clear the whole thing.