Definir módulos en modulemd

Cada modulemd empieza con estas tres líneas:

Les dice a los usuarios lo que este módulo representa escribiendo un resumen y una descripción.

Esta es una licencia de este mismo archivo modulemd y no es necesario modificarlo. El sistema de compilación añade licencias de todos los paquetes a esta lista automáticamente.

Cada configuración de contexto describe como un flujo de módulo y sus componentes se deberían compilar y ejecutar. Un ejemplo de contexto sencillo:

El campo context es obligatorio y debe ser único dentro de un único flujo. El valor es una cadena arbitraria con una longitud y un alfabeto limitados. El valor de contexto se usa por DNF para establecer una ruta de actualización entre múltiples versiones de módulos y contextos. Por lo tanto, una vez establecido el valor, no debería cambiar.

El identificador de la plataforma es obligatorio y coincide con una versión Fedora. Por ejemplo`f32` significa Fedora 32. Rawhide usa también un valor numérico. Técnicamente, es un hilo del módulo platform.

Las dependencias modulares en tiempo de ejecución pueden diferir de las de tiempo de compilación. Puede haber varios módulos enumerados, pero siempre exactamente una secuencia. Por ejemplo, appframework: [v1] significa el flujo de módulo appframework:v1.

A continuación se muestra un complejo ejemplo con múltiples contextos:

Este ejemplo producirá un módulo compilado para Fedora 32 y dos compilados para Fedora 33. El módulo Fedora 32 dependerá de appframework:v1 y frameworkext:v3, mientras que el módulo Fedora 33 soportará los flujos appframework:v1` y appframework:v2. El contexto CTX3 no dependen de frameworkext:v3 porque se fusionó con appframework:v2.

Para ayudar a los usuarios a instalar su módulo, defina perfiles de instalación. Estos perfiles representan un caso de uso específico para su módulo. La mayoría de los módulos tienen al menos un perfil predeterminado. Pero puede especificar más. Por ejemplo, un módulo de base de datos puede tener un perfil servidor y otro cliente.

Enumere todos los paquetes RPM binarios en su módulo que considere la principal característica estable del módulo. Otros paquetes (no listados) deben considerarse no compatibles o un detalle de implementación.

Enumere todos los paquetes SRPM fuente que este módulo debería incluir, haga la referencia por su nombre de repositorio dist-git repo name + el nombre de rama.

Puede proporcionar referencias a la comunidad upstream, a documentación o a un rastreador de problemas.

Los paquetes se compilan en lotes. De modo predeterminado, todos los paquetes son parte de un único grupo y por lo tanto compilados concurrentemente.

Para compilar paquetes en un orden específico, los asigna a múltiples grupos de compilación. Los grupos de compilación se identifican por un entero. Los grupos con números más bajos se compilan primero. Se permiten los valores negativos, 0 es el valor implícito predeterminado.

En este ejemplo específico, first-package se compila primero y second-package se compila segundo.

Para escenarios incluso más complejos, estudie la especificación modulemd-packager.

Los paquetes RPM mientras están siendo compilados como parte de un módulo tienen las siguientes macros RPM disponibles:

Puede usar estas macros en los archivos de especificación RPM de sus componentes RPM para modificar la compilación de los paquetes.

Si necesita macros RPM adicionales, los puede definir en una sección buildopts de su archivo modulemd:

Esta sección pertenece a un elemento de la lista configurations en el caso del formato v3 modulemd. En el caso del formato v2 pertenece directamente a la sección data.

El proceso de compilación de paquetes RPM puede resultar en unos subpaquetes que complementan la compilación del paquete (documentos, requerimientos adicionales de compilación etc.). Un paquete RPM fuente puede producir múltiples paquetes RPM binarios. Estos subpaquetes no siempre se desea que se envíen con el Módulo. Los módulos le habilitan para filtrar estos paquetes no deseables con la opción de compilación filter. Después de que finalice la compilación los paquetes filtrados no serán incluidos en la propiedad artifacts en el archivo modulemd yaml resultante. La propiedad artifacts se añade por el sistema de compilación después de la compilación. Vea un ejemplo en archivos de especificaciones modulemd.

Los RPMs filtrados aún están disponibles como dependencias de compilación en las subsiguientes etapas de la compilación del módulo, pero no se incluyen en el repositorio compuesto para los usuarios.

Si usted decide eliminar un paquete binario de su secuencia del módulo, probablemente dejara de compilarlo o lo filtrará con una opción filter. Pero no es suficiente si desea mover el paquete a paquetes no modulares: Puesto que el paquete permanece listado entre los artefactos en la versión previa de la secuencia y un administrador de paquetes podría ver tanto la versión actualizada como la histórica. (La versión anterior puede estar disponible en los repositorios GA y updates, mientras que su módulo actualizado aparecerá primero en un repositorio updates-testing.)

Para devolver el paquete al conjunto de paquetes no modulares, debe escribirlo en una lista de paquetes desmodularizados. Un administrador de paquetes comprueba la lista desmodularizada de la última versión de la secuencia del módulo en todos los repositorios y si solo ve un nombre de paquete allí, dejará de ocultar los paquetes no modulares con el mismo nombre mientras la secuencia esté habilitada.

La lista de los paquetes desmodularizados se define en el campo demodularized:

Con este mecanismo explícito, llamado desmodularización, un paquete puede ser degradado de un módulo. Si en algún momento revierte su decisión y hace al paquete modular otra vez, lo único necesario es eliminarlo de la lista de desmodularizados.

Además de filtrar subpaquetes, es posible filtrar todos los artefactos producidos por un componente en un módulo. Esto es útil en los casos en que los paquetes principales de su módulo tienen una dependencia en tiempo de compilación que desea enviar. Un ejemplo de tal caso sería si necesita compilar con un generador de documentación especialmente parcheado que entraría en conflicto con la versión predeterminada usada en Fedora.

En este ejemplo, customdocgen se compilaría primero y estaría disponible en buildroot para que myapp lo use durante su compilación. Una vez que la construcción del módulo finaliza y se componen en el repositorio DNF, solo los artefactos no filtrados de myapp estarán disponibles. Todos los artefactos customdocgen se añadirán automáticamente a la sección data.filters.rpms de los metadatos del módulo.

Este módulo incluye dos paquetes RPM fuente creados para las versiones Fedora 35.

Este módulo incluye dos paquetes RPM fuente creados para las versiones Fedora 35. Aclara que paquetes se consideran API y ayuda a los usuarios con la instalación gracias a los perfiles.