Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 23. Software management

The following chapter contains the most notable changes to software management between RHEL 8 and RHEL 9.

23.1. Notable changes to DNF
Copier lien

Software management tools in Red Hat Enterprise Linux 9

In Red Hat Enterprise Linux 9, software installation is ensured by DNF. Red Hat continues to support the usage of the yum term for consistency with previous major versions of RHEL. If you type dnf instead of yum, the command works as expected because both are aliases for compatibility.

Although RHEL 8 and RHEL 9 are based on DNF, they are compatible with YUM used in RHEL 7.

For more information, see Managing software with the DNF tool.

Image mode for RHEL users can use dnf --transient to perform package transactions that reset on reboot

Previously, Image mode for RHEL users could transiently install, remove, and upgrade packages by running the bootc usr-overlay command to unlock the system and then make changes by running DNF commands. If you use bootc usr-overlay, when the system reboots, the /usr directory overlay disappears and all changes made to it will reset. Changes to other directories, including configuration in /etc and program state in /var, persist across reboots.

With RHEL 9.6, a new --transient flag and a new persistence configuration option are added to DNF to improve the user experience on bootc systems. You can skip the bootc usr-overlay step by using either of the following options:

  • Use the dnf --transient command.
  • Set the persistence option to transient in the dnf.conf file.
Note

Unlike when using bootc usr-overlay, --transient and persistence=transient ensure that the /usr directory remains read-only to other processes before, during, and after the transaction.

For example, to transiently install the make package, enter: 

# dnf install --transient make
Copy to Clipboard Toggle word wrap

DNF can verify RPMv6 signatures on RPM packages

Quantum-safe cryptography guarantees integrity and origin of software. However, in quantum computing, standard asymmetric cryptography algorithms, such as RSA, are no longer relevant. Starting from RHEL 9.7, you can use the new multisig DNF plugin to verify RPMv6 signatures on RPM packages, in addition to standard RPMv4 signatures. RPMv6 signatures can be based on quantum-safe algorithms, such as ML-DSA.

To verify RPMv6 signatures, you can install the multisig plugin through the python3-dnf-plugin-multisig RPM package.

Note

Successful verification is a prerequisite for installing, reinstalling, upgrading, or downgrading packages from a repository that has the gpgcheck option set to True.

23.2. Notable changes to RPM
Copier lien

Red Hat Enterprise Linux 9 is distributed with RPM version 4.16.

New SPEC features

In RHEL 9, RPM introduces multiple new SPEC features and enhancements over the previous version, most notably:

  • Fast macro-based dependency generators

    It is now possible to define dependency generators as regular RPM macros. This is especially useful in combination with the embedded Lua interpreter (%{lua:…​}) because it enables writing sophisticated yet fast generators and avoiding redundant forking and executing a shell script.

    Example: 

    %__foo_provides()    %{basename:%{1}}
    Copy to Clipboard Toggle word wrap

  • The %generate_buildrequires section that enables generating dynamic build dependencies

    Additional build dependencies can now be generated programmatically at RPM build time, using the newly available %generate_buildrequires section. This is useful when packaging software written in a language in which a specialized utility is commonly used to determine run-time or build-time dependencies, such as Rust, Golang, Node.js, Ruby, Python or Haskell.

  • Meta (unordered) dependencies

    A new dependency qualifier called meta enables expressing dependencies that are not specifically install-time or run-time dependencies. This is useful for avoiding unnecessary dependency loops that could otherwise arise from the normal dependency ordering, such as when specifying the dependencies of a meta package.

    Example: 

    Requires(meta): <pkgname>
    Copy to Clipboard Toggle word wrap

  • Native version comparison in expressions

    It is now possible to compare arbitrary version strings in expressions by using the newly supported v"…​" format.

    Example: 

    %if v"%{python_version}" < v"3.9"
    Copy to Clipboard Toggle word wrap

  • Caret version operator, opposite of tilde

    The new caret (^) operator can be used to express a version that is higher than the base version. It is a complement to the existing tilde (~) operator which has the opposite semantics.

  • %elif, %elifos and %elifarch statements

  • Optional automatic patch and source numbering

    Patch: and Source: tags without a number are now automatically numbered based on the order in which they are listed.

  • %autopatch now accepts patch ranges

    The %autopatch macro now accepts the -m and -M parameters to limit the minimum and maximum patch number to apply, respectively.

  • %patchlist and %sourcelist sections

    It is now possible to list patch and source files without preceding each item with the respective Patch: and Source: tags by using the newly added %patchlist and %sourcelist sections.

  • A more intuitive way to declare build conditionals

    Starting from RHEL 9.2, you can use the new %bcond macro to build conditionals. The %bcond macro takes a build conditional name and the default value as arguments. Compared to the old %bcond_with and %bcond_without macros, %bcond is easier to understand and allows you to calculate the default value at build time. The default value can be any numeric expression.

    Example:

    • To create a gnutls build conditional, enabled by default: 

      %bcond gnutls 1
      Copy to Clipboard Toggle word wrap

    • To create a bootstrap build conditional, disabled by default: 

      %bcond bootstrap 0
      Copy to Clipboard Toggle word wrap

    • To create an openssl build conditional, defaulting to opposite of gnutls: 

      %bcond openssl %{without gnutls}
      Copy to Clipboard Toggle word wrap

  • %patch N no longer applies a patch number 0

    Previously, when you used the %patch N syntax, where N is the number of a patch, the syntax also applied the patch number 0 (Patch0) in addition to the patch specified by N.

    In RHEL 9.6, the %patch N syntax has been fixed to only apply the patch number N.

    Important

    If you use the %patch directive without a patch number specified, as a shorthand for %patch 0, Patch0 is applied. However, a warning is printed that suggests you use the explicit syntax, for example, %patch 0 or %patch -P 0 instead of %patch to apply the zero-th patch.

RPM database based on sqlite

The RPM database is based on the sqlite library. Read-only support for BerkeleyDB databases has been retained for migration and query purposes.

New rpm-plugin-audit plugin

With this update, you can use a new rpm-plugin-audit plugin for issuing audit log events on transactions, previously built into RPM itself.

Increased parallelism in package builds

There have been numerous improvements to the way the package build process is parallelized. These improvements involve various buildroot policy scripts and sanity checks, file classification, and subpackage creation and ordering. As a result, package builds on multiprocessor systems, particularly for large packages, should now be faster and more efficient.

Enforced UTF-8 validation of header data at build-time

With this update, UTF-8 validation of header data is enforced at build-time.

RPM supports the Zstandard (zstd) compression algorithm

In RHEL 9, the default RPM compression algorithm has switched to Zstandard (zstd). As a result, packages now install faster, which can be especially noticeable during large transactions.

RPM records a checksum of the original package during installation

Starting from RHEL 9.7, RPM records the SHA256 and SHA512 digests of the entire .rpm package during its installation. You can then retrieve these digests from the RPM database to verify that the installed package corresponds to a specific .rpm file. As a result, you can improve the integrity of your RHEL system by retrospectively verifying that the installed package set matches, bit-by-bit, a known set of .rpm packages, such as the ones available in a DNF repository. To print the package digests of an installed package, use the following command: 

$ rpm -q --qf "[%{packagedigestalgos:hashalgo} %{packagedigests}\n]" <package-name>
Copy to Clipboard Toggle word wrap

You can also customize which digest types are recorded in the database by configuring the new %_pkgverify_digests macro, for example: 

%_pkgverify_digests 8:10
Copy to Clipboard Toggle word wrap

RPM supports spec-local file attributes and dependency generators

File attributes and their dependency generators are usually shipped in separate packages that you must install prior to building a package that uses these attributes. However, you might need a file attribute to take effect during the build of the package that ships this attribute. You might also need the file attribute just for building the package, without shipping the attribute at all.

Starting from RHEL 9.7, you can register spec-local file attributes and generators by performing the following actions:

  1. Define the %_local_file_attrs macro. %_local_file_attrs accepts a colon-separated list of new attribute names to register directly in your spec file.
  2. Define one or more dependency generator macros for each attribute, such as %__NAME_provides or %__NAME_path, where NAME is the name of the local file attribute.

RPM then uses the file attributes for dependency generation when the spec file is built. As a result, you can create build-time file attributes that are not necessarily meant for installation.

For example, the following spec file snippet generates the provides for each packaged file by using the foobar.sh script bundled with your package’s sources: 

Source1: foobar.sh
[...]
%define _local_file_attrs foobar
%define foobar_provides %{SOURCE1} %define foobar_path .*
Copy to Clipboard Toggle word wrap
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red HatRetour au début