Packages

Version maintenance is on the agenda right now, so RHEL 8 inherits most of the packages of the Fedora 28 desktop version, including Python 3.6, MariaDB 10.3, PostgreSQL 9.6 and 10, up-to-date Apache and Nginx, and current versions of various tools. If you are not looking for a feature that was only introduced into a tool after Fedora 28, you won't have any problems.

In RHEL 7, the manufacturer has treated the programs in its system like its kernel: Updates are only available in homeopathic doses and certainly not for new program versions or new features. In RHEL 8, the intent is to change this relationship fundamentally. The manufacturer has even rebuilt its package manager, which in itself is a rare event. The current version of the Red Hat Package Manager (RPM) is capable of handling AppStream [2] metadata (see the "AppStream" box).

Repositories

In RHEL 8, the introduction of AppStream ensures that only two repositories need to be enabled on the system for the various package tools: The BaseOS repository, which, as before, contains all core components of the operating system and is subject to the same strict rules that RHEL has been subject to thus far, and the AppStream repository, which contains the majority of applications that mostly run in userspace (Figure  2). Because the appstream directory can also contain different versions of a package, the admin can choose which tool to use during installation.

Figure 2: Only two repositories are enabled by default in RHEL 8. BaseOS contains the basic system, and AppStream contains most of the applications.

The lifecycle of an AppStream application is completely decoupled from that of BaseOS. The basic system thus functions as before and nothing stands in the way of importing new applications via the AppStream mechanism. Because AppStream only makes a statement about the metadata of the software and not about the form in which the data has to be available, containers are very much conceivable in this setup.

The AppStream format is getting ready to become a kind of cross-distribution package manager for containerized applications, which could lead to less diversity but would have the technical advantage that Docker containers can be deployed in a reasonably universal way.

New Yum

Much has also happened with Yum, which is now based on DNF in RHEL 8, a completely new framework that Red Hat built specifically around RPM (Figure 3). Although this change did not really affect the test, according to the manufacturer, Yum is now more robust and, above all, faster than in the previous version. The performance of a tool like Yum also depends on the hardware available on site.

Figure 3: The yum command can still be called, but it is only a link to DNF.

One advantage of DNF over Yum is that it offers a defined and standardized API interface other components can use to access its functionality. Yum had only one approach: on the command line with the yum command, which of course implies all the disadvantages that shell calls to scripts and programs entail.