Pautas de Nomenclatura

Pautas de versionado han sido trasladados

Este documento anteriormente contenía información tanto sobre nombres como sobre versiones. Las pautas de control de versiones ahora están en Empaquetado:Versiones.

Conjunto de Caracteres Comunes para Nombrado de Paquete

Si bien Fedora es una comunidad internacional, para lograr consistencia y usabilidad, es necesario que exista un conjunto de caracteres común para nombrar los paquetes.

En concreto, todos los paquetes de Fedora deben nombrarse utilizando únicamente los siguientes caracteres ASCII. Estos caracteres se exhiben aquí:

abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789-._+

Pero haga comprobar [Separators] para restricciones adicionales en utilizar los caracteres -._+.

Nomenclatura General

Los nombres de los paquetes DEBEN escribirse en minúsculas y usar guiones en lugar de guiones bajos. Puede inspirarse en el nombre del archivo tar original, el nombre del proyecto del que proviene este software y el nombre que otras distribuciones/empaquetadores han usado para este paquete anteriormente. También puede solicitar ayuda a los desarrolladores originales. Sin embargo, no siga estos ejemplos ciegamente, ya que los nombres de los paquetes DEBEN procurar ser consistentes dentro de Fedora más que entre distribuciones.

Además, es posible que el nombre del paquete original no se encuentre dentro del [Conjunto de caracteres común para la nomenclatura de paquetes]. En ese caso, consulte: [Cuando el nombre del paquete en desarrollo está fuera del conjunto de caracteres especificado].

Recuerde también comprobar si el tipo de paquete que está empaquetando tiene reglas específicas para su denominación. «Paquetes fuentes» y los distintos tipos de «Paquetes complementos», por ejemplo.

Separadores

Cuando nombre paquetes para Fedora, el mantenedor DEBE utiliza el guion - como el delimitador para partes del nombre. El mantenedor NO DEBE utilizar un guion bajo _, una suma +, o un punto . como delimitador. Los números de la versión utilizaron en bibliotecas compatibles no necesitan omitir el punto . o cambiarlo a un guión - (consulte [Múltiples paquetes con el mismo nombre base] para más información en este caso).

Hay unas pocas excepciones apara la regla de no subrayado bajo _:

  • Los paquetes adicionales httpd, pam y SDL están excluidos; consulte “Addon Packages (httpd, pam, and SDL)”.

  • los paquetes que son específicos locales, y utilizan el local en el nombre son excluidos, refiérase a “Paquetes de Complemento (locales)”.

  • Los paquetes compactos donde el nombre del paquete base finaliza en un dígito, se refiere a “[Múltiples paquetes con el mismo nombre base]”.

  • los paquete donde el nombre en proyecto naturalmente contiene un guión bajo está excluido desde éste. Ejemplos de estos paquetes incluyen:

    arptables_jf
dhcpv6_client
java_cup
knm_new
libart_lgpl
lm_sensors
microcode_ctl
nss_db
nss_ldap
sg3_utils
tcp_wrappers

Si duda, pregunte en devel@lists.fedoraproject.org.

Cuando el Nombrado En Desarrollo es externo al conjunto del carácter especificado

Fedora reconoce que la tarea de convertir texto al conjunto de carácter especificado de ASCII (esto es transliteración) es difícil. Consiguientemente, cuando el nombre del desarrollo es externo del conjunto de carácter ASCII especificado, el mantenedor del paquete Fedora primero CONTACTARÍA con el desarrollo para que el software y les preguntará por una transliteración del nombre para que lo utilice Fedora.

Si (y sólo si) el desarrollo es incapaz, poco dispuesto, o inutilizable de proporcionar un nombre transliterado, la Fedora packager tiene que escoger a tampoco actuar su propio transliteration, o retirar el paquete de consideración en Fedora.

Cuando decida como transliterar un nombre de paquete, el empaquetador de Fedora MIRARÍA para ver qué otras distribuciones (si hay alguna) han hecho para que el nombre del paquete, y tome eso dentro de la cuenta.

Extra Proporciona

Los paquetes transliterados PUEDEN proporcionar: el original, el nombre no transliterado, pero no es requerido para hacer tanto.

Nombres de Paquetes Conflictivos

Nombres del paquete en conflicto, incluso si difieren por sólo por caso, no es concedido. Consulte Packaging:Conflcts#Conflictos con Nombres de Paquete para más detalles.

Paquetes múltiples con el mismo nombre base

Para muchas razones, es a veces ventajoso de mantener versiones múltiples de un paquete en Fedora para ser instalada simultáneamente. Cuándo haciendo tan, el nombre de paquete TIENE QUE reflejar este hecho. Un paquete TENDRÍA QUE utilizar el nombre de base (sin información de versión). Todos otros paquetes derivaron de él TIENE QUE incluir el nombre de base sufijo por cualquier:

  • La versión del paquete, el cual INCLUIRÍA los periodos presentes en la versión original.

    • Si el nombre del paquete base finaliza con un dígito, un único guion bajo (_) DEBE ser anexado al nombre, y la versión DEBE ser anexada a eso, con el fin de evitar confundir sobre donde finaliza el nombre y donde la versión comienza.

    • Si el nombre de paquete de la base no acaba con un dígito, la versión TIENE QUE ser directamente anexada al nombre de paquete sin intervenir separator.

  • Un guión (-) seguido por un sufijo descriptivo como "estable" el cuál proporciona alguna indicación como a la naturaleza de la versión empaquetada.

Ejemplos:

  • La python-sqlalchemy el paquete ocasionalmente tiene versiones múltiples en Fedora para atrás compatibilidad. La versión más actual de python-sqlalchemy es nombrado python-sqlalchemy y una versión soportada más anterior es python -sqlalchemy0.5. Ningún delimitador está utilizado en esta situación.

  • La versión más actual del v8 el paquete está nombrado v8. Para versión de paquete "3.13", el paquete DEBE ser nombrado como v8_3.13.

También anote que las cadenas tales como "-latest" a menudo puede acaecer con el tiempo pueden volverse engañosos si el paquete (en todas las versiones de Fedora activas) no son mantenidas actualizadas con la última versión en desarrollo.

Paquetes de Documentación con versionado de SO Embebido

Paquetes de documentación (como aprobados por el Proyecto de Documentación de Fedora) puede ser nombrado con el número de versión del SO en el nombre de paquete para conceder instalación paralela de múltiples versiones, en esos casos donde la documentación es concreta a una versión de Fedora y hay valor en tener múltiples versiones simultáneamente instaladas.

Distinguibilidad a Capitalinas

En el empaquetado en Fedora, el mantenedor utiliza su mejor juicio cuando considere como nombrar el paquete. Mientras distinción de capitulinas no es un requisito obligatorio, el caso sólo SERÍA utilizado donde fuese necesario. Conserve en mente dar respeto a los deseas de los mantenedores en desarrollo. Si refieren a su aplicación como "ORBit", UTILIZARÍAS ORBit como el nombre del paquete, y no orbitar. Aun así, si no expresan cualquier preferencia de caso, por defecto se NOMBRARÍA a nombrado en minúsculas.

La excepción a esto es para el empaquetado de módulo en perl. El Grupo y Tipo de CPAN SERÍA estarían capitalizados en el nombre, como si fueran nombres propios. (Refiérase a “Addon Packages (Perl modules)” para más detalles.)

Renombrado/sustitución de paquetes existentes

Consulte: Packaging:Guidelines#Renombrado/Reemplazando de Paquetes Existentes

Sub‐paquetes de Documentación

Archivos de documentación grandes IRÍAN en un subpaquete. Este subpaquete debe ser nombrado con el formato: %{name}-doc . La definición de grande queda al mejor juicio del empaquetados, pero no está restringido al tamaño. Grande puede referir a cualquier tamaño o cantidad grande de archivos.

Paquetes de fuente tipográfica

Los paquetes que contienen las fuentes tipográficas deben ser nombradas como [foundryname-]nombreproyecto[-fontfamilyname]-fuentes, en minúsculas.

Aclaraciones

  1. Para propósitos de Fedora una “fundación” es una entidad que publica un conjunto de fuentes con reglas de QA de la fuente. Por ello un servicio de hospedaje genérico como Sourceforge no es una fundación, pero Open Font Library sí lo es.

  2. Es práctica buena para contratar foundryname- en prefijo breve.

  3. El prefijo de foundryname- opcionalmente puede ser omitido:

    • para entidades que nunca liberaron más de una familia de fuente tipográfica, o

    • cuando el proyecto de fuente tipográfica y la entidad editorial son uno e igual.

  4. Si projectname o foundryname está repetido en fontfamilyname, pueden ser renunciado desde fontfamilyname.

  5. Cuando foundryname, projectname o fontfamilyname contener la fuente o afijo de fuentes, este afijo tendría que ser caído de them[1].

  6. -fontfamilyname no sería incluido en el nombre srpm de un paquete que incluye varias familias de fuente diferentes.

  7. Si cualquier elemento del nombrado contiene espacios, sería sustituido por “-”.

  8. El uso del sufijo -fuentes no es dependiente en el número actual de los archivos de tipografía en el paquete.

Cuando dude, pregunte en el listado de correo para aclaración.

Paquetes Adjuntados

Si un paquete está considerado un paquete "addon" que realza o añade funcionalidad a una Fedora de existir paquete sin ser útil en su propio, su nombre TENDRÍA QUE reflejar este hecho.

El paquete nuevo ("niño") TENER QUE prepend el "antecesor" de paquete en su nombre, en el formato: %{padre}-%{niño}.

Ejemplos:

gnomo-applet-netmon (applet de netmon dependiente de GNOME)
php-adodb (funcionalidad adodb para php, dependiente de php)
python3-torcido (el módulo torcido para python3, dependiente de python3)
xmms-cdread (funcionalidad de lectura cd directa para xmms, dependiente de xmms)

Cuándo el complemento el paquete es una lengua atando, nota que la lengua él es siempre el padre. Así, un lua encuadernación para el "randomdb" la base de datos sería lua-randomdb, no randomdb-lua. También nota que algunos paquetes pueden haber grandfathered nombra utilizar el opuesto ordenando.

Hay algunas excepciones a este paquete adjunto general nombrando normativa, y están anotados a continuación.

httpd, pam, y SDL

Paquetes que confía sobre httpd, pam, o SDL de Apache como el antecesor utiliza un esquema de nombrado diferente. Los adjuntos pam y SDL utilizan el formato: %{parent}_%{child}, con un guion bajo, _, como delimitador. Los adjuntos httpd de Apache utilizan el formato: mod_%{child}, con un guión bajo _ como delimitador. Este esquema de nombrado normalmente es el mimso que el utilizado para el origen del nombre de tarball.

Ejemplos:

mod_perl (Componentes de Perl para httpd de Apache, depende en httpd)
pam_krb5 (Componentes de krb5 para pam, dependiente de pam)
SDL_gfx (Componentes gráficos adicionales para SDL, dependiente de SDL)
SDL_ttf (Fuente tipográfica TrueType representando mantenimiento para SDL, dependiente de SDL)

Componentes de emacs

Paquetes de componentes adjuntados de emacs (código que añade funcionalidad adicional a emacs) TENDRÍA que tener un nombre que tome una nombre de cuenta en desarrollo del componente emacs para ser llamado emacs-$NAME.

Ejemplos:

emacs‐auctex (Componente auctex para GNU Emacs)
emacs‐deferred (Componente diferido para GNU Emacs)
emacs‐flycheck (Componente flycheck para GNU Emacs)

Erlang Módulos

Los paquetes de módulos Erlang (por ello dependen de Erlang como un antecesor) tiene su propio esquema de nombrado. TOMARÍAN en cuenta el nombre de desarrollo del módulo Erlang. Esto hace un formato de nombre del paquete de erlang-$NAME. Cuando dude, utilice el nombre del módulo que se utiliza cuando sea importado en un guion.

Ejemplo:

erlang‐esdl (El módulo Erlang nombrado como esdl)

Paquetes GAP

Consulte Directrices de GAP para el nombrado apropiado de paquetes adjuntados de GAP.

Extensiones de shell en Gnome

Paquetes que extiende la shell de Gnome COMENZARÁ con el prefijo gnome-shell-extension-. En particular, este prefijo NO SERÍA pluralizado (i.e., NO SERÍA +gnome-shell-extensions).

Complementos de GStreamer

Los paquetes que extiendan GStreamer COMENZARÍAN con el prefijo gstreamer1-plugin-. En particular, este prefijo NO SERÍAN pluralizados (i.e., NO SERÍA gstreamer1-plugins) a no ser que sea una colección de complementos (i.e., gstreamer1-plugins-good).

Extensiones LibreOffice

Las extensiones de los paquetes de LibreOffice (por tanto requieren en LibreOffice como antecesor) tiene su propio esquema de nombrando. Deben tomar en cuenta el nombre en desarrollo de la extensión de LibreOffice. Esto lo hace un formato de nombre de paquete del nombre en libreoffice-$NAME.

Regiones

Si un paquete añade un local a un paquete antecesor existent, entonces puede utilizar un guion bajo en el local.

Ejemplos:

ttfonts-zh_TW (añade las fuentes tipográficas zh_TW locales en la familia ttfonts)
ttfonts-zh_CN (añade las fuentes tipográficas zh_CN locales en la familia ttfonts)

Módulos de Lua

Es común que versiones múltiples de Lua es packaged, y cada cual puede tener paquetes de módulo correspondiente. Naturalmente la base Lua los paquetes naturalmente TIENEN QUE seguir el pertinentes nombrando directrices resultando en nombres de paquete como lua5.1.

Los paquetes del módulo LLEVARÍAN el nombre del paquete Lua de la base correspondiente (como mandatario por las directrices pertinentes) como un prefijo. Algunos ejemplos:

Nombre del módulo

versión de lua base

nombre del paquete

argparse

(default)

lua-argparse

argparse

5.1

lua5.1-argparse

sql

5.2

lua5.2-sql

Módulos NGINX

Los paquetes de los módulos NGINX COMENZARÁN con el prefijo nginx-mod-. En particular, este prefijo NO SERÍA pluralizado (i.e., NO TENDRÍA que ser nginx-mods). Algunos proyectos en desarrollo pueden utilizar module como un prefijo, y esto sería contado y sustituido de acuerdo con el nombre del paquete.

Complementos de OBS Studio

Los paquetes de los complementos de OBS Studio COMENZARÍAN con el prefijo obs-studio-plugin-. En particular, este prefijo NO ESTARÍA pluralizado (i.e., NO SERÍA obs-studio-plugins).

Módulos de OCaml

Los módulos, bibliotecas y extensiones de sintaxis de OCaml SERÍAN nombrados ocaml-algo. Ejemplos incluyen: ocaml-extlib, ocaml-ssl.

Esta nomenclatura no se aplica a las aplicaciones escritas en OCaml, las cuales pueden ser dado su nombre habitual. Los ejemplos incluyen: mldonkey, virt-top, cduce

Módulos Perl

Los paquetes de módulos de Perl, (por ello confían en Perl como antecesor) utiliza un ligeramente diferente nombrando esquema. SERÍAN nombrados perl-CPANDIST donde CPANDIST es el nombre de la distribución CPAN empaquetado del módulo (lo cuál también es casi siempre la unidad de Perl empaquetada de módulo). En los casos raros cuando un CPAN necesidades de distribución del módulo para ser partidos a más pequeños subpaquetes p. ej., debido a dependencias, los subpaquetes adicionales SERÍAN nombrados perl-CPANDIST-Algo.

Ejemplos:

perl‐Archive‐Zip (Archivador‐Zip es el nombre de la distribución de CPAN)
perl‐Cache‐Cache (Cache‐Cache es el nombre de la distribución de CPAN)

Módulos de PHP

Para detalles en el esquema del nombrado PHP, consulte Esquema de nombrado.

Módulos Python

Nombrando de módulos de Python están cubiertos completamente en la Sección de nombrado de las Directrices de Empaquetado de Python.

En resumen: el nombre del paquete REFLEJARÍA el nombre en desarrollo del módulo de Python, y generalmente TOMARÍA en cuenta el nombre del módulo utilizado cuando lo importa en guiones de Python. Este nombre será prefijado dependiendo del tipo del paquete.

  • Un paquete de construcción (i.e.distinto de SRPM) para una biblioteca de Python DEBE estar nombrado con el prefijo python3-.

  • Un paquete de fuente que contiene principalmente una biblioteca de Python DEBE ser nombrada con el prefijo de python-.

El carácter + está reservado para Extras.

El nombrado de paquete binario en Python2

Los paquetes binarios de Python 2 DEBEN estar nombrados utilizando un prefijo de python2-. Note que Python 2 está obsoleto en Fedora y requiere una excepción explícita.

Módulos R

Los paquetes de módulos de R (por ello confían en R como antecedente) tiene su propio esquema de nombrando. TOMARÍAN en cuenta el nombre en desarrollo del módulo R. Esto hace un nombre de paquete con formato de R-$NAME. Cuando esté en duda, utilice el nombre del módulo que teclea para importarlo en R.

Ejemplos:

R-mAr (Módulo R nombrado en mAr)
R-RScaLAPACK (Módulo R nombrado en RScaLAPACK)
R-waveslim (Módulo R nombrado en waveslim)

Actividades de Sugar

El nombre para todas las actividades de Sugar empaquetadas deben estar prefijadas con sugar-. Para más detalles, consulte Empaquetado/SugarActivityGuidelines.

Extensiones en Tcl/Tk

El nombre para todas las extensiones empaquetadas de Tcl/Tk deben ser prefijadas con tcl-. Esta regla aplica incluso para paquetes Tcl/Tk que es ya prefijado con tcl en el nombre. Para más detalles, consulte Packaging/Tcl#NamingConventions.

TeX

Como Fedora ha cambiado los entornos en TeX en el pasado, los paquetes TeX no SERÍAN nombrados tras el entorno TeX (TeX Live o teTeX) pero en cambio LLEVARÍA el prefijo tex-.

Autoría

El autor original de estas directrices era Tom olla Callaway. Ahora están mantenidos por el Comité de Empaquetado con entrada desde la comunidad Fedora.

1. Para evitar paquetes foofont-fonts de fuentes tipográficas.

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