What's inside an RPM .repo file?

The previous article in this series, How does RPM package discovery work?, described how the RPM package management technology discovers and installs an .rpm package on a local computer running the Red Hat Enterprise Linux, Fedora, or CentOS Stream operating system. In that article, you learned that the .repo files stored in the /etc/yum.repos.d directory of the local machine play a critical role in discovering, installing, and managing RPM packages.

This article goes to the next level of detail to describe the format specified for a .repo file.

This article describes not only the format specification for a .repo file but also describes the logic that's applied to a .repo file when managing RPM packages on a given machine. But, before delving in, let's review how RPM discovers a package on the internet and then installs it.

Understanding RPM package discovery and installation

dnf (or yum) finds a package to install by doing a lookup on what is called a repository manifest file. This file might exist locally in the dnf (or yum) cache of the local machine, which is where dnf will look first to find a reference to the package location. If the package reference can't be found in the local cache, dnf install looks in the .repo files in the directory /etc/yum.repos.d to get the URL of the repository associated with the .repo file under examination.

dnf install has the intelligence to parse and analyze the information in the .repo file to locate the actual manifest file that describes the .rpm packages stored in the given remote repository.

If there is no reference to the .rpm file for the package of interest, dnf install moves on to the next .repo file in the /etc/yum.repos.d directory. Once the .rpm file is located, dnf install does the work of installing the package on the local machine. This is all illustrated in Figure 1.

If dnf install can't locate the package reference using the .repo files in /etc/yum.repos.d, it will respond with an error.

As you can see, .repo files play a pivotal role in the RPM ecosystem. Understanding them is essential to those interested in how RPM works under the covers. So, let's take a look at the structure of a .repo file.

Anatomy of a .repo file

The listing below shows an excerpt of the contents of the file /etc/yum.repos.d/fedora.repo. The file fedora.repo is usually present on a computer running Fedora Server or Desktop. The file is a good candidate for analysis:

[fedora]
name=Fedora $releasever - $basearch
#baseurl=http://download.example/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
enabled=1
countme=1
metadata_expire=7d
repo_gpgcheck=0
type=rpm
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False

[fedora-debuginfo]
name=Fedora $releasever - $basearch - Debug
#baseurl=http://download.example/pub/fedora/linux/releases/$releasever/Everything/$basearch/debug/tree/
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-debug-$releasever&arch=$basearch
enabled=0
metadata_expire=7d
repo_gpgcheck=0
type=rpm
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False
.
.
.

The structure of a .repo file is predefined according to specification. Table 1 is a list of the more common fields defined in the specification.

As noted, when you run dnf install, the command will inspect the .repo files in the /etc/yum.repos.d directory to locate an appropriate repository. Once the repository is located, dnf install will execute according to the parameters defined as fields in the given .repo file.

You can learn about all the specified fields for a .repo file by reading the dnf documentation.

Viewing a list of repositories

The information in a .repo file is used not only to populate available packages using dnf install but also as the source of data for the dnf repolist command, which informs the system which repositories are enabled.

The listing below shows a list of repositories returned when executing the command dnf repolist. The listing has two column headings, repo id and repo name. These two columns are displayed by default.

repo id                                                   repo name
fedora                                                    Fedora 35 - x86_64
fedora-cisco-openh264                                     Fedora 35 openh264 (From Cisco) - x86_64
fedora-modular                                            Fedora Modular 35 - x86_64
updates                                                   Fedora 35 - x86_64 - Updates
updates-modular                                           Fedora Modular 35 - x86_64 - Updates

An interesting point to note is that values for the repo IDs and names are extracted directly from the .repo file for the corresponding repository—fedora.repo, in this case. For example, when you look back to the first listing above, you'll see that the .repo file has the following in the first two lines of content:

[fedora]

name=Fedora $releasever - $basearch

The dnf repolist command extracts the value fedora from the [fedora] entry in the file fedora.repo. The value for the repo name, Fedora 35 - x86_64 is extracted from the name field of the .repo file, which is declared as Fedora $releasever - $basearch.

At this point, you may be wondering: how does the string Fedora $releasever - $basearch transform into Fedora 35 - x86_64? As it happens, $releasever and $basearch are variables that get resolved at runtime.

And how are their values determined? Well, to determine the value of $releasever variable, check the /etc/fedora-release file. It should contain a line like this:

Fedora release 35

To determine the value of the $basearch variable, type the following at the command line:

$ uname -i

The command should return a response similar to the following:

X86_64

Working with the cache

As you read earlier, the dnf install command checks the local computer's cache for repository information before taking the time to go to the internet to locate and install RPM packages.

Typically, the dnf cache on a local machine running RHEL, Fedora, or CentOS Stream is in the directory /var/cache/dnf/.

You can list the contents of the dnf cache by executing this command:

ls /var/cache/dnf/

The following listing shows some sample contents of the /var/cache/dnf/ directory.

$ ls -lh /var/cache/dnf/


total 9.5M

drwxr-xr-x. 4 root root   38 Jul 14 10:39 copr:copr.fedorainfracloud.org:group_redhat-et:microshift-4288080f6baba874

-rw-r--r--. 1 root root    2 Jul 14 15:57 expired_repos.json

drwxr-xr-x. 4 root root   38 Jul 14 15:56 fedora-37d3cae0527b6391

drwxr-xr-x. 3 root root   22 Jul 14 15:56 fedora-cisco-openh264-1ed815b676713aa8

drwxr-xr-x. 3 root root   22 Jul 14 15:56 fedora-modular-cd949c6b43ea9b3d

-rw-r--r--. 1 root root    0 Jul 14 14:06 last_makecache

-rw-r--r--. 1 root root 9.5M Jul 14 13:30 packages.db

drwxr-xr-x. 2 root root    6 Jul 14 14:06 rpms.famillecollet.com_enterprise_remi-release-7.rpm-31d898f8b7b0a3bc

-rw-r--r--. 1 root root    2 Jul 14 13:30 tempfiles.json

drwxr-xr-x. 4 root root   38 Jul 14 15:56 updates-7eea87b22825bc0d

drwxr-xr-x. 4 root root   38 Jul 14 15:56 updates-modular-67de45f4f37a0461

Not only are there files that are dedicated to a particular repo, such as the fedora-37d3cae0527b639, which maps to the fedora repository; there are also files that are particular to managing the cache, such as packages.db.

The command to clean out the cache and start afresh is sudo dnf clean all.

Getting repository information from the local SQLite database

RPM does more than store repository information in the cache or .repo files. When a package is installed, RPM makes entries into a SQLite database hosted on the local computer. This database is dedicated to RPM activity and is located in the host computer's /var/lib/rpm directory.

The SQLite entries describe metadata about the package that's been installed. You use rpm -qi to get information from the SQLite database about a particular package. This listing shows an example of executing the rpm -q -i jq command to get information about the jq utility, which is used to parse and filter JSON files.

$ rpm -q -i jq


Name        : jq

Version     : 1.6

Release     : 9.el9

Architecture: x86_64

Install Date: Mon 30 May 2022 02:07:40 PM PDT

Group       : Unspecified

Size        : 400049

License     : MIT and ASL 2.0 and CC-BY and GPLv3

Signature   : RSA/SHA256, Wed 11 Aug 2021 05:50:53 PM PDT, Key ID 05b555b38483c65d

Source RPM  : jq-1.6-9.el9.src.rpm

Build Date  : Mon 09 Aug 2021 03:22:17 PM PDT

Build Host  : x86-02.stream.rdu2.redhat.com

Packager    : builder@centos.org

Vendor      : CentOS

URL         : http://stedolan.github.io/jq/

Summary     : Command-line JSON processor

Description :

lightweight and flexible command-line JSON processor


 jq is like sed for JSON data – you can use it to slice

 and filter and map and transform structured data with

 the same ease that sed, awk, grep and friends let you

 play with text.


 It is written in portable C, and it has zero runtime

 dependencies.


 jq can mangle the data format that you have into the

 one that you want with very little effort, and the

 program to do so is often shorter and simpler than

 you'd expect.

You can also view information from the SQLite database that has RPM repository data directly by using a SQLite client. You install SQLite and the client using this command:

sudo dnf install sqlite

After it's been installed, you gain access to the RPM using the SQLite client by executing the following command:

$ sqlite3 /var/lib/rpm/rpmdb.sqlite 

Once the client is invoked, you can use SQLite commands and queries at the prompt of the SQLite client to set and get information in the SQLite RPM/dnf database. This listing shows the command that produces a list of tables in the SQLite database.

sqlite> .tables


Basenames             Name                  Sigmd5              

Conflictname          Obsoletename          Suggestname         

Dirnames              Packages              Supplementname      

Enhancename           Providename           Transfiletriggername

Filetriggername       Recommendname         Triggername         

Group                 Requirename         

Installtid            Sha1header  

Putting it all together

The RPM installation process is pretty ingenious. It's no small feat to set things up so that a single command executed in a terminal window does the enormous amount of work required to find and install the multitude of components required to run a particular application on a RHEL, Fedora, or CentOS Stream computer. There's a good argument to be made that the RPM package manager helped bring Linux into the mainstream for business and home users.

At the center of it all is the .repo file. The standardization inherent in a .repo file provides the predictability that is essential to making RPM work. The RPM discovery and installation process based on a standard .repo file specification makes it so all RPM packages are installed in the same manner on any computer running RHEL, Fedora, or CentOS Stream. It's an amazing feat.

Understanding the details of a .repo file as described in this article is an important next step for working with RPM beyond general usage, particularly when you start developing your own RPM packages. Hopefully, the information provided in the article will help make it easier for you to move forward working with RPM.