On a Linux system, it is possible to install software in two ways:
Using an installation package;
Compiling from source files.
Note
Installing from source is not covered here. As a rule, you should use the package method unless the software you want is not available via the package manager. The reason for this is that dependencies are generally managed by the package system, whereas with source, you need to manage the dependencies manually.
The package: This is a single file containing all the data needed to install the program. It can be executed directly on the system from a software repository.
The source files: Some software is not provided in packages ready to be installed, but via an archive containing the source files. It is up to the administrator to prepare these files and compile them to install the program.
RPM (RedHat Package Manager) is a software management system. It is possible to install, uninstall, update or check software contained in packages.
RPM is the format used by all RedHat based distributions (RockyLinux, Fedora, CentOS, SuSe, Mandriva, ...). Its equivalent in the Debian world is DPKG (Debian Package).
The name of an RPM package follows a specific nomenclature:
The rpm command also allows you to query the system package database by adding the -q option.
It is possible to execute several types of queries to obtain different information about the installed packages. The RPM database is located in the directory /var/lib/rpm.
Example:
rpm-qa
This command queries all the packages installed on the system.
rpm-q[-a][-i][-l]package[-f]file
Example:
rpm-qilpackage
rpm-qf/path/to/file
Option
Description
-a
Lists all packages installed on the system.
-i __package__
Displays the package information.
-l __package__
Lists the files contained in the package.
-f
Shows the name of the package containing the specified file.
--last
The list of packages is given by installation date (the last installed packages appear first).
Warning
After the -q option, the package name must be exact. Metacharacters (wildcards) are not supported.
Tip
However, it is possible to list all installed packages and filter with the grep command.
DNF (Dandified Yum) is a software package manager, successor of YUM (Yellow dog Updater Modified). It works with RPM packages grouped in a local or remote repository (a directory for storing packages). For the most common commands, its usage is identical to that of yum.
The dnf command allows the management of packages by comparing those installed on the system with those in the repositories defined on the server. It also automatically installs dependencies, if they are also present in the repositories.
dnf is the manager used by many RedHat based distributions (RockyLinux, Fedora, CentOS, ...). Its equivalent in the Debian world is APT (Advanced Packaging Tool).
Removes all packages installed as dependencies but no longer needed.
The dnf install command allows you to install the desired package without worrying about its dependencies, which will be resolved directly by dnf itself.
In case you don't remember the exact name of the package, you can search for it with the command dnf search name. As you can see, there is a section that contains the exact name and another one that contains the package correspondence, all of which are highlighted for easier searching.
Another way to search for a package by entering an additional search key is to send the result of the dnf command through a pipe to the grep command with the desired key.
Sometimes you only know the executable you want to use but not the package that contains it, in this case you can use the command dnf provides */package_name which will search the database for you for the desired match.
The dnf repolist command lists the repositories configured on the system. By default, it lists only the enabled repositories but can be used with these parameters:
Groups are a collection of a set of packages (you can think of them as a virtual packages) that logically groups a set of applications to accomplish a purpose (a desktop environment, a server, development tools, etc.).
The dnf grouplist command lists all available groups.
Note that it is good practice to enclose the group name in double quotes as without the command it will only execute correctly if the group name does not contain spaces.
So a dnf groupinstall Network Servers produces the following error.
The DNF manager relies on one or more configuration files to target the repositories containing the RPM packages.
These files are located in /etc/yum.repos.d/ and must end with .repo in order to be used by DNF.
Example:
/etc/yum.repos.d/Rocky-BaseOS.repo
Each .repo file consists of at least the following information, one directive per line.
Example:
[baseos] # Short name of the repository
name=Rocky Linux $releasever - BaseOS # Short name of the repository #Detailed name
mirrorlist=http://mirrors.rockylinux.org/mirrorlist?arch=$basearch&repo=BaseOS-$releasever # http address of a list or mirror
#baseurl=http://dl.rockylinux.org/$contentdir/$releasever/BaseOS/$basearch/os/ # http address for direct access
gpgcheck=1 # Repository requiring a signature
enabled=1 # Activated =1, or not activated =0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rockyofficial # GPG public key path
By default, the enabled directive is absent which means that the repository is enabled. To disable a repository, you must specify the enabled=0 directive.
Modules were introduced in Rocky Linux 8 by the upstream. In order to use modules, the AppStream repository must exist and be enabled.
Package Confusion
The creation of module streams in the AppStream repository caused a lot of people confusion. Since modules are packaged within a stream (see our examples below), a particular package would show up in our RPMs, but if an attempt was made to install it without enabling the module, nothing would happen. Remember to look at modules if you attempt to install a package and it fails to find it.
Modules come from the AppStream repository and contain both streams and profiles. These can be described as follows:
module streams: A module stream can be thought of as a separate repository within the AppStream repository that contains different application versions. These module repositories contain the application RPMs, dependencies, and documentation for that particular stream. An example of a module stream in Rocky Linux 8 would be postgresql. If you install postgresql using the standard sudo dnf install postgresql you will get version 10. However, using modules, you can instead install versions 9.6, 12 or 13.
module profiles: What a module profile does is take into consideration the use case for the module stream when installing the package. Applying a profile adjusts the package RPMs, dependencies and documentation to account for the module's use. Using the same postgresql stream in our example, you can apply a profile of either "server" or "client". Obviously, you do not need the same packages installed on your system if you are just going to use postgresql as a client to access a server.
You can obtain a list of all modules by executing the following command:
dnf module list
This will give you a long list of the available modules and the profiles that can be used for them. The thing is you probably already know what package you are interested in, so to find out if there are modules for a particular package, add the package name after "list". We will use our postgresql package example again here:
dnf module list postgresql
This will give you output that looks like this:
Rocky Linux 8 - AppStream
Name Stream Profiles Summary
postgresql 9.6 client, server [d] PostgreSQL server and client module
postgresql 10 [d] client, server [d] PostgreSQL server and client module
postgresql 12 client, server [d] PostgreSQL server and client module
postgresql 13 client, server [d] PostgreSQL server and client module
Notice in the listing the "[d]". This means that this is the default. It shows that the default version is 10 and that regardless of which version you choose, if you do not specify a profile, then the server profile will be the profile used, as it is the default as well.
Using our example postgresql package, let's say that we want to enable version 12. To do this, you simply use the following:
dnf module enable postgresql:12
Here the enable command requires the module name followed by a ":" and the stream name.
To verify that you have enabled postgresql module stream version 12, use your list command again which should show you the following output:
Rocky Linux 8 - AppStream
Name Stream Profiles Summary
postgresql 9.6 client, server [d] PostgreSQL server and client module
postgresql 10 [d] client, server [d] PostgreSQL server and client module
postgresql 12 [e] client, server [d] PostgreSQL server and client module
postgresql 13 client, server [d] PostgreSQL server and client module
Here we can see the "[e]" for "enabled" next to stream 12, so we know that version 12 is enabled.
Now that our module stream is enabled, the next step is to install postgresql, the client application for the postgresql server. This can be achieved by running the following command:
dnf install postgresql
Which should give you this output:
========================================================================================================================================
Package Architecture Version Repository Size
========================================================================================================================================
Installing group/module packages:
postgresql x86_64 12.12-1.module+el8.6.0+1049+f8fc4c36 appstream 1.5 M
Installing dependencies:
libpq x86_64 13.5-1.el8 appstream 197 k
Transaction Summary
========================================================================================================================================
Install 2 Packages
Total download size: 1.7 M
Installed size: 6.1 M
Is this ok [y/N]:
After approving by typing "y" you installed the application.
It's also possible to directly install packages without even having to enable the module stream! In this example, let's assume that we only want the client profile applied to our installation. To do this, we simply enter this command:
dnf install postgresql:12/client
Which should give you this output:
========================================================================================================================================
Package Architecture Version Repository Size
========================================================================================================================================
Installing group/module packages:
postgresql x86_64 12.12-1.module+el8.6.0+1049+f8fc4c36 appstream 1.5 M
Installing dependencies:
libpq x86_64 13.5-1.el8 appstream 197 k
Installing module profiles:
postgresql/client
Enabling module streams:
postgresql 12
Transaction Summary
========================================================================================================================================
Install 2 Packages
Total download size: 1.7 M
Installed size: 6.1 M
Is this ok [y/N]:
Answering "y" to the prompt will install everything you need to use postgresql version 12 as a client.
After you install, you may decide that for whatever reason, you need a different version of the stream. The first step is to remove your packages. Using our example postgresql package again, we would do this with:
dnf remove postgresql
This will display similar output as the install procedure above, except it will be removing the package and all of its dependencies. Answer "y" to the prompt and hit enter to uninstall postgresql.
Once this step is complete, you can issue the reset command for the module using:
dnf module reset postgresql
Which will give you output like this:
Dependencies resolved.
========================================================================================================================================
Package Architecture Version Repository Size
========================================================================================================================================
Disabling module profiles:
postgresql/client
Resetting modules:
postgresql
Transaction Summary
========================================================================================================================================
Is this ok [y/N]:
Answering "y" to the prompt will then reset postgresql back to the default stream with the stream that we had enabled (12 in our example) no longer enabled:
Rocky Linux 8 - AppStream
Name Stream Profiles Summary
postgresql 9.6 client, server [d] PostgreSQL server and client module
postgresql 10 [d] client, server [d] PostgreSQL server and client module
postgresql 12 client, server [d] PostgreSQL server and client module
postgresql 13 client, server [d] PostgreSQL server and client module
Now you can use the default.
You can also use the switch-to sub-command to switch from one enabled stream to another. Using this method not only switches to the new stream, but installs the needed packages (either downgrade or upgrade) without a separate step. To use this method to enable postgresql stream version 13 and use the "client" profile, you would use:
There may be times when you wish to disable the ability to install packages from a module stream. In the case of our postgresql example, this could be because you want to use the repository directly from PostgreSQL so that you could use a newer version (at the time of this writing, versions 14 and 15 are available from this repository). Disabling a module stream, makes installing any of those packages impossible without first enabling them again.
To disable the module streams for postgresql simply do:
dnf module disable postgresql
And if you list out the postgresql modules again, you will see the following showing all postgresql module versions disabled:
Rocky Linux 8 - AppStream
Name Stream Profiles Summary
postgresql 9.6 [x] client, server [d] PostgreSQL server and client module
postgresql 10 [d][x] client, server [d] PostgreSQL server and client module
postgresql 12 [x] client, server [d] PostgreSQL server and client module
postgresql 13 [x] client, server [d] PostgreSQL server and client module
EPEL (Extra Packages for Enterprise Linux) is an open-source and free community-based repository maintained by the EPEL Fedora Special Interest Group that provides a set of additional packages for RHEL (and CentOS, Rocky Linux, and others) from the Fedora sources.
It provides packages that are not included in the official RHEL repositories. These are not included because they are not considered necessary in an enterprise environment or deemed outside the scope of RHEL. We must not forget that RHEL is an enterprise class distribution, and desktop utilities or other specialized software may not be a priority for an enterprise project.
The package, as you can see from the package description above, does not contain executables, libraries, etc... but only the configuration files and GPG keys for setting up the repository.
Another way to verify the correct installation is to query the rpm database.
rpm-qa|grepepel
epel-release-8-14.el8.noarch
Now you need to run an update to let dnf recognize the repository. You will be asked to accept the GPG keys of the repositories. Clearly, you have to answer YES in order to use them.
dnfupdate
Once the update is complete you can check that the repository has been configured correctly with the dnf repolist command which should now list the new repositories.
And below we can see the contents of the file epel.repo.
[epel]name=ExtraPackagesforEnterpriseLinux$releasever-$basearch# It is much more secure to use the metalink, but if you wish to use a local mirror# place its address here.#baseurl=https://download.example/pub/epel/$releasever/Everything/$basearchmetalink=https://mirrors.fedoraproject.org/metalink?repo=epel-$releasever&arch=$basearch&infra=$infra&content=$contentdirenabled=1gpgcheck=1countme=1gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
[epel-debuginfo]name=ExtraPackagesforEnterpriseLinux$releasever-$basearch-Debug
# It is much more secure to use the metalink, but if you wish to use a local mirror# place its address here.#baseurl=https://download.example/pub/epel/$releasever/Everything/$basearch/debugmetalink=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-$releasever&arch=$basearch&infra=$infra&content=$contentdirenabled=0gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
gpgcheck=1[epel-source]name=ExtraPackagesforEnterpriseLinux$releasever-$basearch-Source
# It is much more secure to use the metalink, but if you wish to use a local mirror# place it's address here.#baseurl=https://download.example/pub/epel/$releasever/Everything/source/tree/metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-$releasever&arch=$basearch&infra=$infra&content=$contentdirenabled=0gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
gpgcheck=1
At this point, once configured, we are ready to install the packages from EPEL. To start, we can list the packages available in the repository with the command:
From the command we can see that to install from EPEL we must force dnf to query the requested repository with the options --disablerepo and --enablerepo, this is because otherwise a match found in other optional repositories (RPM Fusion, REMI, ELRepo, etc.) could be newer and therefore have priority. These options are not necessary if you have only installed EPEL as an optional repository because the packages in the repository will never be available in the official ones. At least in the same version!
Support consideration
One aspect to consider regarding support (updates, bug fixes, security patches) is that EPEL packages have no official support from RHEL and technically their life could last the space of a development of Fedora (six months) and then disappear. This is a remote possibility but one to consider.
So, to install a package from the EPEL repositories you would use:
EPEL is not an official repository for RHEL, but it can be useful for administrators and developers who work with RHEL or derivatives and need some utilities prepared for RHEL from a source they can feel confident about.
After running a dnf update, the running processes will continue to run but with the old binaries. In order to take into account the code changes and especially the security updates, they have to be restarted.
The needs-restarting plugin will allow you to detect processes that are in this case.
dnf needs-restarting [-u] [-r] [-s]
Options
Description
-u
Only consider processes belonging to the running user.
Sometimes it is useful to protect packages from all updates or to exclude certain versions of a package (because of known problems for example). For this purpose, the versionlock plugin will be of great help.
You need to install an extra package:
dnf install python3-dnf-plugin-versionlock
Examples:
Lock the ansible version:
dnf versionlock add ansible
Adding versionlock on: ansible-0:6.3.0-2.el9.*
List locked packages:
dnf versionlock list
ansible-0:6.3.0-2.el9.*
Author: Antoine Le Morvan
Contributors: Colussi Franco, Steven Spencer, Ganna Zhyrnova