Using AppStreams to install different versions of software – Revisiting Modules and AppStreams
Using AppStreams to install different versions of software
Now, we’re going to expand on what we know about AppStreams, and instead of installing an application from the default module stream, we’re going to specify a different stream.
How to do it…
There are multiple ways to do this: simply specifying the installation of a different stream will get the job done, or you can first manually enable a different version. My preference is to specify the version as I install it because, in that case, the AppStream will automatically enable that version:
#dnf module install nodejs:16
NOTE
If you already installed some version of an AppStream, it is best to remove the old one before resetting and installing a different version. This will be covered later.
The output is shown in the following screenshot:

Figure 10.11 – Output of dnf module install nodejs:16
You’ll see from the printout that the module stream for nodejs 16 will be enabled. Now, if we list out the module stream for nodejs, we’ll see the following:

Figure 10.12 – Output of dnf module list nodejs
As you can see, 10 is still the default, but 16 is enabled (e). AppStreams maintains a default stream to allow normal usage of dnf to function without requiring the user to know anything about AppStreams. Additionally, if we were to reset the module, it would revert back to the original settings – that is, it would make 10 the only default and enabled version, and version 16 would no longer be enabled. Furthermore, it’s important to note that only one stream can be enabled at a time. To recap, a default stream is inherently enabled when no other stream is enabled. If you enable a different stream, it is the only one that can be installed from, but it’s easy to reset and switch to another. To do so, simply do the following:
#dnf module remove nodejs
#dnf module reset nodejs
You will see confirmation about the module being reset:
Disabling module profiles:
nodejs/common
Resetting modules:
nodejs
At this point, we are cleared to install a different version. Let’s go with Node.js 14 this time around:
#dnf module install nodejs:14
You will see a confirmation about what the package manager plans to do:

Figure 10.13 – Output of dnf module install nodejs:14
You may notice that you are downgrading. Just as you might suspect, if no module is installed, it will say Installing; if installing a number that is greater than the currently installed version, it will say Upgrading; and if installing a number that is less than the currently installed version, it will say Downgrading. Regardless of what the package manager says it is doing, you will be left with the version you requested – it’s as simple as that.
You should be aware there is another way to switch to a different stream. Rather than using remove, reset, and then install, you can achieve this with one step by using switch-to:

Figure 10.14 – Output of dnf module switch-to nodejs:16
This is the recommended method of changing stream versions because it accomplishes the change in just one step, and it provides a very clear printout of the action taking place. Its status is Upgrading, and it is going from 14 -> 16.
NOTE
There is actually another way to switch modules on the fly. If you set module_stream_switch to True in /etc/dnf/dnf.conf, then you can install a different module without using the switch-to syntax.
Here is an example:
echo “module_stream_switch=True” >> /etc/dnf/dnf.conf
What about Python?
If you review the list of modules, you may notice that Python consists of multiple modules rather than a single module with multiple AppStreams:
#dnf module list python*
The output can be seen in the following screenshot:

Figure 10.15 – Output of dnf module list python*
This seems weird at first, but consider that Python is an integral part of the Oracle Linux operating system and that each Oracle Linux release comes with a platform Python version. The specific platform Python version may differ for each Oracle Linux release, and the respective platform Python version will be supported for the full lifespan of that version of Oracle Linux. For Oracle Linux 7, the platform Python version is 2.7 and is always installed, and for Oracle Linux 8, the platform Python version is 3.6. In other words, Python 2.7 is supported for the full lifespan of Oracle Linux 7, and Python 3.6 is supported for the full lifespan of Oracle Linux 8. On Oracle Linux 8, the platform Python is exclusively intended for use by system utilities such as Yum and DNF. Python for general purpose is not installed by default on Oracle Linux 8, and so this is where AppStream modules come into play.
You can install multiple versions of Python on Oracle Linux 8 by specifying the module correlating to the desired version of Python. All of the Python modules can be installed and used simultaneously on the same machine, and you can specify which installation you wish to use by typing out the version – for example, python3.6 –version, python3.8 –version, and so on.
By default, the python3 command is always aliased to Python 3.6 if it is installed on the system, and that is because Python 3.6 is the platform Python version on Oracle Linux 8.