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
[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.
[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.
[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.
Want to help? Learn how to contribute to Fedora Docs ›