Añadir nuevos módulos a Fedora

El proyecto Modularity ha sido retirado y no hay sin módulos en Fedora 39 o posterior o en EPEL. Esta página sólo se conserva como referencia histórica.

Esta página le guiará a través de todo el proceso de añadir un nuevo módulo a Fedora:

  1. [Fuentes RPM] — Para `dist-git/rpms`utilizando ramas de flujo

  2. Definición del módulo — Para `dist-git/modules`utilizando ramas de flujo.

  3. [Módulo Construir] — El módulo se construye como una unidad. No se construyen paquetes individuales.

  4. Publicación del módulo — Enviar una actualización de Bodhi.

Fuentes de RPM

Para cada paquete de su módulo, debe tener un archivo Fedora Distribution Git (dist-git) repository bajo `dist-git/rpms`con un rama del flujo apropiado. Los nuevos paquetes deben pasar por una revisión de paquetes.

Repositorios y Ramas de Flujo — Nuevos paquetes

El Proceso de revisión de paquetes de Fedora cubre todos los pasos que hay que dar, excepto las ramas de los arroyos. Para ello, continúe más abajo para ver los paquetes existentes.

Repositorios y ramas de flujos — Paquetes existentes

La solicitud de nuevas ramas de flujo para paquetes existentes se realiza con fedpkg, y no requiere una revisión del paquete.

Para crear una nueva rama para un paquete que comparte nombre con el módulo (por ejemplo, "postgresql"), ejecute el siguiente comando que creará la rama de flujo del paquete, así como el módulo y su rama de flujo juntos:

$ fedpkg request-branch --repo=NOMBRE RAMA --sl NIVEL_SERVICIO:AAAA-MM-DD

  • NOMBRE — nombre del paquete y del módulo

  • RAMA — nombre de la rama de flujo del paquete y el módulo

  • SERVICE_LEVEL:AAAA-MM-DD — fin de vida previsto (e.g. bug_fixes:2020-12-01). La fecha debe terminar con 12-01 o 06-01. Existen varios niveles de servicio bug_fixes, security_fixes, y rawhide. En este momento, esto se utiliza para bloquear la rama de empujar nuevos commits allí. Puede cambiar la fecha más tarde con un billete releng. Las fechas actuales se almacenan en Centro de Definición de Productos. Otra opción es elegir una fecha lejana en el futuro para que no te afecte. (Se está trabajando para solucionarlo.)

Si este paquete no comparte nombre con el módulo (como en el caso de las dependencias), entonces solicite sólo la rama flujo para este paquete:

$ fedpkg request-branch --repo=NAME BRANCH --no-auto-module --sl NIVE _SERVICIO:AAAA-MM-DD

  • --no-auto-module — Omitir la creación de un módulo con el mismo nombre

La creación del módulo y de sus ramas de flujo por separado se tratará más adelante.

Importar las fuentes RPM en dist-git

Lo último que hay que hacer es importar las fuentes RPM en dist-git. Consulte the Nuevo proceso de paquetes para los contribuyentes existentes para ver los pasos completos.

Definición del módulo

Para la definición de su módulo, también necesita tener un dist-git repositorio, esta vez bajo dist-git/modules, con un rama del flujo. Los nuevos módulos también tienen que pasar por un revisión del módulo en Bugzilla respetando Pautas de empaquetado de módulos de Fedora.

Repositorios y Ramas de Flujo — Nuevos módulos

Para solicitar un nuevo repositorio de módulos en dist-git run:

$ fedpkg request-repo --namespace modules NOMBRE DEFECTO
$ fedpkg request-branch --namespace modules --repo NOMBRE RAMA --sl NIVEL_SERVICIO:AAAA-MM-DD

Repositorios y ramas de flujo — Módulos existentes

para solicitar una nueva rama de flujo, ejecute:

$ fedpkg solicitud-rama --namespace módulos --repo NOMBRE RAMA --sl NIVEL_DE_SERVICIO:AAAA-MM-DD

  • NOMBRE — nombre del módulo

  • RAMA — nombre de la rama de flujo del módulo

  • NIVEL_SERVICIO:AAA-MM-DD — fin de vida previsto. Consulte arriba para más detalles.

Escriba y pulse el botón modulemd

La escritura de un módulomd se trata en detalle en the Definición de módulos en modulemd sección.

El nombre del modulemd debe coincidir con el nombre del repositorio. Recuerde reemplazar cada NOMBRE en el siguiente ejemplo. 
$ fedpkg clone modules/NOMBRE
$ cd NOMBRE
$ fedpkg switch-branch RAMA
$ vim NOMBRE.yaml
$ git add NAME.yaml
$ git commit -m "añade el modulemd inicial"
$ git push

  • NOMBRE — nombre del módulo

  • RAMA — nombre de la rama de flujo del módulo

Módulo Construido

NOTA: Con la Modularidad, ya no se construyen paquetes individuales. En su lugar, debe enviar la compilación de un módulo.

El envío de compilaciones de módulos se realiza mediante fedpkg y está cubierto en el Módulos de construcción sección.

Publicación del módulo

To make your module available to users, submit as an update to Fedora Bodhi. Make sure you are logged in, and then click on Create / New Update at the top-right corner. Fill out the following fields:

  • Candidate Builds: MODULE_BUILD_ID

  • Update notes: notes for the users

  • Final details: check what applies

One way of getting the MODULE_BUILD_ID is running the same command as in the previous step:

$ fedpkg module-build-info BUILD_ID

and changing the "koji tag" value in the following way:

module-nodejs-10-20180607142235-6c81f848   <- koji tag
       nodejs-10-20180607142235.6c81f848   <- MODULE_BUILD_ID

that is removing the "module-" part at the beginning, and replacing the last "-" with a ".".

Also you can do the same with help of command-line bodhi client:

$ bodhi updates new --type=enhancement --notes="Update to 3.0." --user FAS_USER MODULE_BUILD_ID
================================================================================
     MODULE_BUILD_ID
================================================================================
   Update ID: FEDORA-MODULAR-2019-cee54ead99
Content Type: module
     Release: Fedora 28 Modular
      Status: pending
        Type: enhancement
       Karma: 0
   Autokarma: False  [-3, 3]
     Request: testing
       Notes: Update to 3.0.
   Submitter: FAS_USER
   Submitted: 2019-01-23 11:14:56
    Comments: bodhi - 2019-01-23 11:14:56 (karma 0)
              This update has been submitted for testing by
              FAS_USER.

  https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-cee54ead99

where FAS_USER is your Fedora Project user name.

Módulo Flujo EOLing/Obsoleting

Cuando un flujo ya no debe utilizarse, se puede indicar al usuario que lo migre añadiendo un documento Módulo obsoleto.

Want to help? Learn how to contribute to Fedora Docs ›