Removing packages via AppStream

Removing packages via AppStream is straightforward. In general, all you need to do is instruct the package manager to remove instead of install. If the package manager finds a module that matches, it will proceed to remove the related packages.

How to do it…

Building off the examples in the previous recipe, let’s remove the Node.js module by running the dnf module remove nodejs command:

Figure 10.16 – Output of dnf module remove nodejs

From this message, you can see that NPM will be uninstalled, but that isn’t quite what you would expect considering that the Node.js module installed more than just NPM. If you want to remove everything related to the module, you’ll need to pass in the –all flag, like so:
# dnf module remove nodejs –all

This time, you will see that all associated packages are queued for removal:

Figure 10.17 – Output of dnf module remove nodejs –all

Now that’s more like it. Type y and press Enter, and the module will be removed.

There’s more…

So, now that we’ve gone over the usage of AppStreams, you might be asking yourself, “Didn’t we already have a similar capability with Software Collections?” The answer is yes, but there is a big difference between Software Collections and AppStreams.

Where Software Collections provides Parallel Availability and Parallel Installability, AppStreams provides only Parallel Availability.

According to the Fedora docs, “Parallel Availability means that more than one major release of a popular software project is available for installation.” And “Parallel Installability means that more than one major release of a software project can be installed on the same userspace.”

Now you might be asking, “Wait, so you’re telling me that AppStreams is not as good as what we had before?” Well, not exactly. It turns out that Parallel Installability isn’t all it’s cracked up to be. Although it seems nice on the surface to have the ability to install multiple versions of software on the same system, in reality, it is plagued with complications of requiring users to know they need to do something extra in order to actually make use of the installed software and/or alternate version. For example, if you wanted to install multiple versions of Node.js, you would first need to enable the desired Software Collection for Node.js, and then you would also need to know where to look for and activate the specific version you want to use. In other words, you cannot simply use the alternate version of the software in the normal way because the packages would get installed in non-standard locations.

AppStreams solves this because it does not allow for Parallel Installability; instead, it provides the capability of Parallel Availability. In other words, you install one and only one package at a time, and you use it like you normally would. If you want a different version, well, you simply enable a different stream.

As a bonus, AppStreams is particularly useful when creating containers that are single-use by design. Having AppStreams means each container image is configured with the right version of the module, which is then globally available within the container. If you need multiple versions, just run multiple containers.

AppStreams makes it much easier to install different versions of software, and the best thing is, even if you know nothing about AppStreams, you can still use DNF the old-fashioned way and get your basic applications installed.