Red Hat Enterprise Linux 8 pre-series test

Stable Future

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).

AppStream

The term "AppStream" is currently making the rounds in the IT world with at least two meanings: as a product for AWS from Amazon and as a package component metadata standard. AppStream support in RPM obviously refers to the latter: It is simply an approach to retrieving software dynamically from a central repository. Where RPM, dpkg, and the various other tools used to use their own metadata, a central repository containing generic metadata is now being created instead, and it is up to the manufacturers to decide the content that will fill these data structures, as well as the way in which they implement their packages.

At the end of the day, the AppStream standard makes it possible, for example, to handle an application packaged in a Docker container in the same way as a conventional package – with the usual package manager on the local system.

The important difference is that you can install several versions of the same package on one system at the same time, which is why the RPM changes were necessary: All common package managers today work strictly according to the principle that only one version of each package can be installed at a time.

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.

« Previous 1 2 3 4 Next »