NSVCA vs NEVRA
Denominación e identificación de módulos en Fedora
Con la introducción de Modularity (Modularidad) en el ecosistema de empaquetadores también se presentaron varios desafíos. Primero que la convención de denominación de paquete NEVRA (name-epoch-version-release-architecture) (nombre-época-versión-lanzamiento-arquitectura) usada en Fedora era insuficiente. Los módulos se identifican de forma única mediante la convención de nomenclatura NSVCA, que se encuentra para name, stream, version, context, and architecture (nombre, flujo, versión, contexto y arquitectura). Está página describe la ID a nivel fuente (NSV) y la ID a nivel binario (NSVCA).
ID de módulo a nivel fuente (NSV)
En el nivel fuente, los módulos solo se identifican por los tres primeros: name, stream, and version (nombre, flujo y versión). Nombre se define como un nombre del repositorio del módulo en DistGit, flujo es el nombre de la rama en DistGit y versión es el sello de tiempo de una confirmación.
Nombre
El nombre del módulo corresponde al nombre de la aplicación o la pila de lenguajes que representa. Un ejemplo de un nombre podría ser postgresql para un módulo de base de datos PostgreSQL o nodejs para un Node.js en tiempo de ejecución.
Flujo
Los flujos son variantes de un módulo con cierta promesa.
En la mayoría de los casos, los flujos prometen compatibilidad con versiones anteriores de la aplicación o la pila de lenguajes que proporcionan. Por ejemplo, digamos que Node.js en tiempo de ejecución soporta dos versiones principales: 6 y 8. En este caso, el módulo nodejs tendría dos flujos: 6 y 8.
Sin embargo, los flujos pueden prometer cosas diferentes, como estabilidad. Un buen ejemplo de esto es el paquete calc en Fedora que es mantenido en dos ramas upstream: stable para la última versión estable y unstable para la última versión en desarrollo. Utilizando la modularidad, este paquete podría ser compilado como módulo calc en dos flujos diferentes: estable e inestable.
Además de la promesa de la versión, los flujos son también una manera para que los empaquetadores comuniquen el nivel de mantenimiento. ¿El mantenedor planea aplicar todos los parches menores? ¿Aplicarán correcciones de seguridad rápidamente? o ¿Se actualiza el módulo solo dos veces al año? Esto puede también ser parte de la promesa.
Otro ejemplo diferente podría ser un flujo que proporciona software compilado utilizando algunas banderas experimentales para incrementar el rendimiento.
De todos modos, entiende la idea. Los flujos son una herramienta muy flexible y poderosa. Úselos sabiamente.
Versión
Las versiones son solo actualizaciones de un flujo dado. Técnicamente, la versión es un número generado por el sistema de construcción. Gana siempre el número más alto. Esto significa que la versión no identifica una versión principal/secundaria del software sino la actualización/envío de un flujo en particular.
Identificación a Nivel Binario (NSVCA)
La compilación de un módulo desde una fuente puede llevar a múltiples binarios diferentes. Los diferentes binarios se producen, normalmente, para diferentes arquitecturas (esto es, x86_64, armv7hl, etc.) y diferentes lanzamientos de Fedora (esto es, Fedora 28, Fedora 29, EPEL 7, etc.).
Los módulos binarios utilizan NSVCA completo — por lo tanto, además de los campos nombres, flujo y versión descritos anteriormente, hay dos más para los binarios: arquitectura y contexto.
Arquitectura
Fedora está diseñado para muchas arquitecturas diferentes. El campo arquitectura, simplemente, distingue los binarios específicos de arquitectura entre ellas. El valor suele ser el mismo que con los paquetes RPM, esto es x86_64, armv7hl, etc.
Contexto
El contexto se usa para distinguir los binarios compilados para diferentes versiones de Fedora. Gracias a la expansión de los flujos, los módulos también se pueden construir contra múltiples flujos de otros módulos, esto es, diferentes versiones de un lenguaje de tiempo de ejecución, etc.
El valor es generado por el sistema de construcción y, normalmente, está oculto para el usuario y no tiene ningún valor informativo por si mismo — es un hash. Sin embargo, las herramientas del cliente que consumen este valor pueden presentarlo de forma útil.
Una manera de representar el contexto podría ser listando las versiones de Fedora para las que ha sido construido cierto módulo.
Definición NSVCA
Esto define la política de nomenclatura para los metadatos modulemd de los módulos finales (construidos). Esta política NO se aplica a fuentes como modulemd yaml en dist-git.
El objetivo es proporcionar identificadores únicos para los módulos que sean legibles por los humanos y también adecuados para el procesamiento por las máquinas.
Formas
Una forma es una secuencia de campos que identifican total o parcialmente un módulo.
Formas Completas
- N:S:V:C:A
-
Identificador único de un módulo.
- N:S:V:C:A/P
-
Identificador único del perfil de un módulo.
Formas Parciales
Las formas parciales admitidas son: N [ : S [ :V [ :C ] ] ] [ :A ] [ /P ]
A saber:
-
N -
N::A -
N:S -
N:S::A -
N:S:V -
N:S:V::A -
N:S:V:C -
N:S:V:C:A(idéntica aN:S:V:C::A) -
y todas las combinaciones con
/P
Los campos que falten DEBERÍAN completarse con los valores predeterminados recomendados:
- Flujo
-
el valor predeterminado es el flujo habilitado o predeterminado del sistema para el módulo en este orden en particular
- Versión
-
el valor predeterminado es la última versión disponible en el flujo del módulo
- Contexto
-
el valor predeterminado a un valor que coincida con módulos ya instalados o módulos involucrados en la transacción (no instalados todavía)
- Arquitectura
-
el valor predeterminado a la arquitectura del sistema (por ejemplo, $basearch de DNF)
- Perfil
-
el valor predeterminado al predeterminado del sistema o el perfil 'default'
Caracteres Permitidos
- N - Nombre
-
a-z A-Z 0-9 . - _
- S - Flujo
-
a-z A-Z 0-9 . - _
- V - Versión
-
0-9
- C - Contexto
-
0-9 a-f
- A - Arquitectura
-
a-z A-Z 0-9 . - _
- P - Perfil
-
a-z A-Z 0-9 . - _
Todos los campos DEBEN empezar y terminar con un carácter alfanumérico: a-z A-Z 0-9
Caracteres Prohibidos
Este párrafo sirve como un diseño de decisión para futuros cambios.
Los siguientes caracteres NO DEBEN ser parte de ningún campo:
-
:(dos puntos) - separador -
/(barra) – separador de perfil -
\(barra invertida) – carácter común de control -
*(asterisco) – comodín común -
?(interrogación) – comodín común -
@(arroba) – especificación grp en YUM y DNF -
` ` (espacio) – separador común
Want to help? Learn how to contribute to Fedora Docs ›