Usar módulos en Fedora

Los Módulos son grupos especiales de paquetes que normalmente representan a una aplicación, un tiempo de ejecución de lenguaje o un conjunto de herramientas. Están disponibles en una o varios flujos que generalmente representan una versión principal de un software, dándole a usted la opción de elegir que versiones de los paquetes desea consumir.

Para simplificar la instalación, los módulos normalmente definen uno o más perfiles de instalación que representan un caso de uso específico. Por ejemplo un perfil server (servidor) o un perfil client (cliente) en un módulo de base de datos.

Esto es un rápida visión general de como usar los módulos y las secuencias de módulos con el administrador de paquetes DNF.

Instalación y descubrimiento de flujos de módulos

Listar paquetes

Los paquetes disponibles al sistema se pueden descubrir con los comandos usuales como dnf search NAME, dnf list NAME o usando el comando dnf repoquery QUERY para consultas más complejas. Sin embargo, es importante tener en cuenta que estos comandos solo listarán, aparte de los paquetes tradicionales, paquetes modulares que vengan de un flujo de módulo ya habilitado.

Listar módulos

Para listar los módulos disponibles en su sistema y ver que flujos son predeterminados o han sido habilitados, utilice el siguiente comando:

    $ dnf module list

Instalar paquetes

Los paquetes se pueden instalar del modo habitual ejecutando el comando dnf install NAME. Cualquier paquete tradicional o un paquete modular que venga de un módulo habilitado puede ser instalado de este modo.

Los paquetes de otros flujos de módulos pueden ser consumidos habilitando el flujo de módulo y después instalando los paquetes individuales o instalando un módulo directamente.

Habilitar módulos

Para habilitar un flujo de módulo y hacer sus paquetes disponibles para su instalación, ejecute el siguiente comando:

    $ dnf module enable NAME:STREAM

Por ejemplo, para hacer los paquetes Node.js 8 disponibles para su instalación, ejecute:

    $ dnf module enable nodejs:8

Los paquetes de los flujos de módulo habilitados pueden ser instalados entonces con el comando dnf install NAME.

Instalar módulos

Para instalar un módulo, use uno de los siguientes comandos. Al no especificar un flujo o un perfil se provoca que DNF elija el predeterminado. Sin embargo, no todos los módulos tienen un flujo predeterminado o un perfil predeterminado. En estos casos usted necesita especificar el flujo o el perfil explícitamente.

    $ dnf module install NAME
    $ dnf module install NAME:STREAM
    $ dnf module install NAME/PROFILE
    $ dnf module install NAME:STREAM/PROFILE

Por ejemplo, para instalar el tiempo de ejecución de Node.js 8 y las herramientas del cliente del flujo predeterminado de MongoDB, ejecute:

    $ dnf module install nodejs:8
    $ dnf module install mongodb/client

Cambio de flujos de módulos

El cambio de flujos puede ser una operación arriesgada que puede no estar admitida en los paquetes, especialmente las degradaciones.

Cambiar a un flujo diferente de uno que está instalado en el sistema se hace con el argumento switch-to.

    $ dnf module switch-to NAME:STREAM

Un ejemplo, para cambiar de Node.js 8 a Node.js 10, ejecute:

    $ dnf module switch-to nodejs:10

Un ejemplo, para cambiar de Node.js 10 a Node.js 8, ejecute:

    $ dnf module switch-to nodejs:8
El argumento switch-to es la manera preferida y recomendada de cambiar flujos.

El argumento switch-to incluye múltiples acciones que necesitan ser ejecutadas para cambiar de forma segura a otro flujo de módulo.

En este ejemplo mostramos un cambio manual de Node.js 8 a Node.js 10 sin ejecutar el argumento switch-to:

    $ dnf remove nodejs
    $ dnf module reset nodejs:8
    $ dnf module enable nodejs:10
    $ dnf install nodejs
El comando dnf module info NAME:STREAM es útil para comprobar los RPMs en un flujo de módulo.

Actualizar el sistema

Actualizar un sistema ejecutando el comando dnf update origina que todos los paquetes sean actualizados a la última versión proporcionada por su flujo de módulo.

Eliminar módulos

En general, para eliminar un módulo instalado en su sistema, use el siguiente comando:

    $ dnf module remove MODULE:STREAM/PROFILE

Avanzado

Hay una situación cuando un paquete específico ha sido instalado primero y un módulo se ha instalado después de eso. Ejemplo:

    $ dnf install ruby
    $ dnf module install ruby:2.6/default

En este caso, ejecutar el comando dnf module remove no eliminaría el paquete ruby, ya que DNF recuerda que el paquete ha sido instalado explícitamente.

Para hacer que el paquete ruby se desinstale con el comando dnf module remove, ejecute lo siguiente:

    $ dnf mark group ruby
    $ dnf module remove ruby:2.6/default

Esto se debe a que DNF recuerda el motivo por el cual se instaló el paquete. Hay tres, ordenados desde el más fuerte:

  • usuario

  • grupo

  • dependency

Because modules use the group reason, which is weaker than user used by the dnf install command, the package stays on the system after running the dnf module remove command. "Downgrading" it to group, however, makes the dnf module remove remove it as well.

Modular filtering and conflicts

When consuming module streams a lot of operations are being executed. A module stream contains alternative modular RPM packages which can have the same name as already existing non-modular RPM packages, a lot of conflicts can arise. In the next few examples we will show you some of the conflicts.

Switching a module stream without removing the RPM packages from the old module stream

Example 1. broken dependencies when switching module streams without removing the installed content
[root@5e7d134a8883 /]# dnf module install nodejs:14/common
Last metadata expiration check: 0:02:38 ago on Thu Mar  3 08:57:00 2022.
Dependencies resolved.

 Problem 1: cannot install the best candidate for the job
  - nothing provides /usr/bin/pwsh needed by nodejs-1:14.19.0-2.module_f35+13766+ad18d3e5.x86_64
 Problem 2: package npm-1:6.14.16-1.14.19.0.2.module_f35+13766+ad18d3e5.x86_64 requires nodejs = 1:14.19.0-2.module_f35+13766+ad18d3e5, but none of the providers can be installed
  - cannot install the best candidate for the job
  - nothing provides /usr/bin/pwsh needed by nodejs-1:14.19.0-2.module_f35+13766+ad18d3e5.x86_64
===========================================================================================================================================================================
 Package                             Architecture              Version                                                            Repository                          Size
===========================================================================================================================================================================
Upgrading:
 nodejs                              x86_64                    1:14.17.2-2.module_f35+12348+fe4be0bd                              fedora-modular                      93 k
 nodejs-docs                         noarch                    1:14.17.2-2.module_f35+12348+fe4be0bd                              fedora-modular                     6.0 M
 nodejs-full-i18n                    x86_64                    1:14.17.2-2.module_f35+12348+fe4be0bd                              fedora-modular                     7.8 M
 nodejs-libs                         x86_64                    1:14.17.2-2.module_f35+12348+fe4be0bd                              fedora-modular                      13 M
Downgrading:
 npm                                 x86_64                    1:6.14.13-1.14.17.2.2.module_f35+12348+fe4be0bd                    fedora-modular                     3.3 M
Installing module profiles:
 nodejs/common
Skipping packages with broken dependencies:
 nodejs                              x86_64                    1:14.19.0-2.module_f35+13766+ad18d3e5                              updates-modular                    199 k
 npm                                 x86_64                    1:6.14.16-1.14.19.0.2.module_f35+13766+ad18d3e5                    updates-modular                    3.3 M

Transaction Summary
===========================================================================================================================================================================
Upgrade    4 Packages
Downgrade  1 Package
Skip       2 Packages

Total download size: 30 M
Is this ok [y/N]:

In this situation we enabled and installed the nodejs:12 module stream on Fedora 35. Then we reset the 12 stream and enabled the 14 stream. After that we wanted to install the nodejs:14 module stream.

First DNF is trying to upgrade or downgrade the existing installed software. It will not remove the existing software during the execution of the reset argument. The reset only disables the enabled stream of a module. The NEVRAs of the RPM files in the module stream can have different versions from the installed software (newer or older) and also from other streams from the same module. The runtime dependencies can be different between RPM packages from different module streams.

This conflict is correct and is not a bug. As you are trying to update installed RPM packages from the 12 stream with RPM packages from the 14 stream. Module streams from the same module are mutually exclusive and only one stream at a time should be enabled and installed.

If you are switching streams and not sure about the manual process, please use the switch-to argument as this is the recommended way.

Installing a RPM package from a wrong module stream.

Example 2. of a RPM package requested to be installed from the wrong module stream
[root@bdaeaab947e6 /]# dnf module enable perl:5.30
Fedora 35 - x86_64                                                                                                                         6.8 MB/s |  79 MB     00:11
Fedora 35 openh264 (From Cisco) - x86_64                                                                                                   3.1 kB/s | 2.5 kB     00:00
Fedora Modular 35 - x86_64                                                                                                                 2.8 MB/s | 3.3 MB     00:01
Fedora 35 - x86_64 - Updates                                                                                                               7.3 MB/s |  27 MB     00:03
Fedora Modular 35 - x86_64 - Updates                                                                                                       2.3 MB/s | 2.8 MB     00:01
Dependencies resolved.
===========================================================================================================================================================================
 Package                                  Architecture                            Version                                   Repository                                Size
===========================================================================================================================================================================
Enabling module streams:
 perl                                                                             5.30

Transaction Summary
===========================================================================================================================================================================

Is this ok [y/N]: y
Complete!
[root@bdaeaab947e6 /]# dnf install perl-Tie-RefHash
Last metadata expiration check: 0:00:22 ago on Thu Mar  3 09:41:23 2022.
Error:
 Problem: package perl-Tie-RefHash-1.40-478.fc35.noarch requires perl(:MODULE_COMPAT_5.34.0), but none of the providers can be installed
  - conflicting requests
  - package perl-libs-4:5.34.0-481.fc35.i686 is filtered out by modular filtering
  - package perl-libs-4:5.34.0-481.fc35.x86_64 is filtered out by modular filtering
  - package perl-libs-4:5.34.0-482.fc35.i686 is filtered out by modular filtering
  - package perl-libs-4:5.34.0-482.fc35.x86_64 is filtered out by modular filtering
(try to add '--skip-broken' to skip uninstallable packages)
[root@bdaeaab947e6 /]#

The example describes a situation when you try to install a RPM package which is not provided from the enabled perl:5.30 module stream. We first enable the perl:5.30 module stream. After that we are trying to install the package perl-Tie-RefHash. The DNF package manager is trying to tell you that the perl-Tie-RefHash cannot be installed because it is not provided by any of the enabled module streams. Modular filtering will automatically filter out all the RPM packages which are not provided by the actual enabled module streams.

To fix this conflict you have to enable the correct module stream. In our case it is the perl:5.32 module stream.

Installing a RPM package without enabling the module stream which provides it.

Example 3. of a installation conflict when installing a package without enabling the correct module stream
[root@bdaeaab947e6 /]# dnf install perl-DBI
Last metadata expiration check: 3:13:30 ago on Thu Mar  3 09:41:23 2022.
Error:
 Problem: package perl-DBI-1.643-10.fc35.x86_64 requires libperl.so.5.34()(64bit), but none of the providers can be installed
  - conflicting requests
  - package perl-libs-4:5.34.0-481.fc35.x86_64 is filtered out by modular filtering
  - package perl-libs-4:5.34.0-482.fc35.x86_64 is filtered out by modular filtering
(try to add '--skip-broken' to skip uninstallable packages)
[root@bdaeaab947e6 /]# dnf module enable perl-DBI
Last metadata expiration check: 3:14:38 ago on Thu Mar  3 09:41:23 2022.
Dependencies resolved.
===========================================================================================================================================================================
 Package                                  Architecture                            Version                                   Repository                                Size
===========================================================================================================================================================================
Enabling module streams:
 perl-DBI                                                                         1.643

Transaction Summary
===========================================================================================================================================================================

Is this ok [y/N]: y
Complete!
[root@bdaeaab947e6 /]# dnf install perl-DBI
Last metadata expiration check: 3:14:46 ago on Thu Mar  3 09:41:23 2022.
Dependencies resolved.
===========================================================================================================================================================================
 Package                          Architecture                   Version                                                      Repository                              Size
===========================================================================================================================================================================
Installing:
 perl-DBI                         x86_64                         1.643-7.module_f35+12493+425c54a8                            fedora-modular                         700 k

Transaction Summary
===========================================================================================================================================================================
Install  1 Package

Total download size: 700 k
Installed size: 1.9 M
Is this ok [y/N]:

In this example we are trying to install the perl-DBI package. On our system we have previously enabled and installed the perl:5.32 module stream. The conflict tells us that we are trying to install non-modular perl-DBI which depends on the non-modular perl but the non-modular perl package is not available due to modular filtering. The only RPM packages which are available for dependency resolution are the RPM packages from the 5.32 stream.

Non-modular RPM packages can not depend on modular content. If your non-modular package needs a modular dependency please modularize your content.

To fix this we need to enable the perl-DBI:1.643 module stream. When enabling the perl-DBI:1.643 we are satisfying the modular dependency for the perl module. The non-modular perl-DBI RPM package is now filtered by modular filtering and it is not considered in dependency resolution and content set creation.