Packaging talk:Guidelines/es

Guía de Empaquetado

Es responsabilidad del revisor señalar problemas específicos con un paquete y es responsabilidad del empaquetador manejar esos problemas. El revisor y el empaquetador trabajan en conjunto para determinar el grado de severidad del problema (si se bloquea el paquete o se puede manejar después de que el paquete se encuentre en el repositorio.) La Guía de Empaquetamiento es una colección de problemas comunes y el grado de severidad que debe ser puesto en ellos. Mientras que estas guías no deben ser ignoradas, tampoco deben seguirse a ciegas. Si usted piensa que su paquete debería exento de parte de la guía, puede comunicarle su inquietud al Comité de Empaquetado de Fedora.

Por favor recuerde que cualquier paquete que usted envíe debe ajustarse a la Guía de Revisión.

Autor: Tom 'spot' Callaway (basado en muchos otros documentos)
Revision: 1.01
Borrador Inicial: Miércoles 23 de febrero, 2005
Última Revisión: Viernes 4 de febrero, 2011

Nombrado

Usted debe seguir la Guía de Nombramiento para asegurarse que su paquete está nombrado apropiadamente.

Versión y Publicación

La documentación que cubre la manera adecuada de utilizar los campos Versión y Publicación pueden ser encontrados aquí: Packaging:NamingGuidelines#Package_Version

Legal

Hay varios aspectos legales que considerar cuando se empaqueta para Fedora.

Licenciamiento

Usted debería revisar el Licensing:Main y la Guía de Licenciamiento para segurarse de que su paquete está licenciado de manera apropiada.

Paquetes que no son útiles sin bits externos

Algunos programas no son funcionales o útiles sin la presencia de dependencias de código externo al ejecutarlos en el entorno del sistema operativo. Cuando estas dependencias de código externo no son gratis, es legalmente inaceptable, o solo binario (con excepción de algunos firmwares permisibles), entonces el programa dependiente no es aceptable para su inclusión en Fedora. Si el código dependiente es aceptable para Fedora, entonces ellos deben ser empacados e incluidos en Fedora como un pre-requisito para la inclusión del software dependiente. Programas que permiten descargar grupos de paquetes de Internet para que sean funcionales o útiles no son aceptables para ser incluidos en Fedora (independientemente de si el código descargado sería aceptable para ser empacados en Fedora como una dependencia apropiada).

Esto también significa que paquetes que no son funcionales o útiles sin código o paquetes de terceros no son aceptados para ser incluidos en Fedora.

No incluir binarios pre-construidos o librerías

Todos los binarios del programa y las librerías de programas incluidas en los paquetes de Fedora deben ser construidas desde el código fuente que está incluido en la fuente del paquete. Esto es un requerimiento por las siguientes razones:

• Seguridad: Programas binarios pre-empaquetados y librerias de programas no construidas del código fuente pueden contener partes maliciosas, peligrosas o rotas. Además son imposibles de reparar.
• Banderas del Compilador: Programas Binarios pre-empaquetados y librerías de programas no construidas desde el código fuente probablemente no fueron compiladas con las banderas estándar de Fedora para seguridad y optimización.

Contenido binario (como archivos .pfd, .png, .ps) no son requeridos para reconstruir desde el código fuente.

Si tiene alguna duda sobre si algo es considerado un programa binario o una biblioteca de programas, he aquí algunos criterios útiles:

• ¿Es un ejecutable? si es así, posiblemente sea un programa binario.
• Contiene una extensión .so, so.#, o .so.#.#.#? si es así, es probable que sea una librería de programas.
• Si está en duda, consulte con su revisor. Si el revisor no está seguro, entonces debe preguntar al Comité de Empaquetado de Fedora.

Paquetes que requieren de componentes propietarios para construirse tampoco son permitidos (ej. requiere un compilador propietario).

Cuando usted se encuentra con binarios pre-construidos usted DEBE:

• Remover todo los programas binarios pre-construidos y las librerías de programas en %prep antes de la construcción del paquete. Ejemplos incluidos, pero no están limitados a archivos *.class, *.dll, *.DS_Store, *.exe, *.jar, *.o, *.pyc, *.pyo, *.egg, *.so.
• Pregunte arriba para remover los binarios en sus próximos lanzamientos.

Excepciones

• Algunos programas (usualmente relacionados a compiladores o ambientes de compiladores cruzados) no pueden ser construidos primero sin el uso de herramientas de cadena o ambiente de desarrollo (código abierto). Si usted tiene un paquete que coincide con este criterio, contacte al Comité de Empaquetado de Fedora para aprobación.
• Se ha hecho una excepción para firmware binario, mientras cumpla con los requerimientos encontrados aquí: Licensing:Main#Binary_Firmware
• Algunos programas binarios pre-empacados o librerías de programas bajo términos que no permiten su distribución o pueden ser afectados por escenarios legales como patentes. En estos casos, borrar simplemente los archivos en %prep no es suficiente, el mantenedor va a tener que hacer una fuente modificada para que no contenga estos archivos. Ver: Packaging:SourceURL#When_Upstream_uses_Prohibited_Code

Legibilidad de las Especificaciones

Todos los archivos de Especificaciones de los paquetes de Fedora deben ser legibles. Si el revisor no puede leer el archivo de especificaciones, será imposible hacer una revisión. Los archivos de especificaciones de Fedora no es el lugar para entradas de Concurso de Código Ofuscado.

Escribiendo un paquete desde Cero

Cuando está escribiendo un paquete desde cero, usted debe basar su archivo de especificaciones en la plantilla de archivos de especificaciones de Fedora (ver Rpmdevtools). Por favor, ponga a un lado sus preferencias de formato y organización del archivo de especificaciones e intente cumplir con esta plantilla lo más posible. No es que creamos que esta es la única manera correcta de escribir un archivo de especificaciones, sino que a menudo le hace más fácil al control de calidad encontrar errores y entender rápidamente lo que usted está tratando de hacer.

Modificando un paquete existente

Si usted basa su paquete en un paquete existente que no es de Fedora, tenga el cuidado de verificarlo con exactitud y entender exactamente que está pasando. No envíe un paquete sin saber que hacen esos extraños, pero aparentemente inocentes comandos.

En particular, usted debe

• verificar cualquier fuente o parche.
• verificar que la licencia que está en el archivo de especificaciones concuerde con la licencia actual del programa (ver Tags ).
• Revise el resumen y la descripción por errores tipográficos y rarezas (ver Resumen y Descripción ),
• Asegúrese que el uso de macros es consistente (ver Macros ).

Mantenga la vieja entrada de registros de cambio para darle crédito a los autores originales. Entrada que son de hace muchos años o se refieren a versiones antiguas del programa pueden ser borrada. Si usted termina haciendo cambios radicales y reescribe gran parte del archivo de especificaciones siéntase libre de iniciar el archivo de registros de cambio desde 0. En otras palabras, utilice su mejor juicio.

Arquitecturas Soportadas

Todos los paquetes de Fedora deben poder compilarse y construirse en archivos rpms con éxito en al menos una de las arquitecturas primarias soportadas. Los empaquetadores de Fedora deben hacer el esfuerzo de soportar todas las arquitecturas primarias.

Contenido, código que no necesita ser compilado o creado y la arquitectura de código independiente (noarch) son excepciones notables.

Fallos de Compilación en la Arquitectura

Si un paquete Fedora no compila, se construye o trabaja con éxito en una arquitectura, entonces esas arquitecturas deberán estar mencionadas en las especificaciones en ExcludeArch. Cada arquitectura mencionada en ExcludeArch debe contener un error en bugzilla, describiendo la razón del porque el paquete no compila/crea/trabaja en esa arquitectura. El número de error deberá ser puesto en un comentario, seguido de la línea ExcludeArch correspondiente. Los paquetes nuevos no tendrán entradas en bugzilla durante el proceso de evaluación, así que deberán poner esta descripción en los comentarios hasta que el paquete haya sido aprobado, después archivar la entrada en bugzilla, y reemplazar la larga explicación con el número de error. El error deberá ser marcado como bloqueando uno (o más) de los siguientes errores para simplificar el seguimiento de esos errores:

• FE-ExcludeArch-x86
• FE-ExcludeArch-x64
• FE-ExcludeArch-ppc
• FE-ExcludeArch-ppc64
• F-ExcludeArch-arm
• F-ExcludeArch-s390x
• F-ExcludeArch-sparc

Diseño del Sistema de Archivos

Fedora sigue el Estándar de Jerarquía de Sistemas de Archivos (FHS) con respecto al diseño del sistema de archivos. El FHS define donde los archivos deben ser puestos en un sistema. Los paquetes de Fedora deben seguir el FHS. Cualquier desviación del FHS deberá ser racionalizada cuando el paquete es revisado.

Algunas interpretaciones del FHS dicen que el FHS no previene a las distribuciones de crear y utilizar directorios fuera de la lista de jerarquías (por ejemplo, la adición de nuevos directorios de nivel superior a / o añadir nuevos directorios bajo /usr). Para el propósito de la Guía de Empaquetado de Fedora, nuevos directorios de este tipo no están permitidos al menos que estén mencionados en las Guías. Si usted siente la necesidad de un nuevo directorio, por favor póngase en contacto con la FPC justificando el porque del directorio y a que categoría de programa pertenece ese directorio. Pueda que usted tenga que leer el FHS para saber si un directorio ya forma parte de una jerarquía aprobada por la FHS.

Hay excepciones notables para la guía libexecdir (cómo se especifica en Código Estándar GNU), /run (El cual ha sido ampliamente adoptado por distribuciones linux a pesar que no ha salido una nueva versión del FHS que lo incluya) y /usr/target para compiladores cruzados.

Libexecdir

El Estándar de Jerarquía de Sistemas de Archivos no incluye ninguna provisión para libexecdir, pero los paquetes de Fedora pueden guardar ahí archivos apropiados. Libexecdir (también conocido como, /usr/libexec en sistemas Fedora) debería ser usado como el directorio para programas ejecutables que son primeramente diseñados para ser ejecutados por otros programas en vez de otros usuarios.

Los paquetes rpm de Fedora incluyen un macro para libexecdir, %{_libexecdir}. Es altamente recomendable que los Empaquetadores guarden los archivos libexecdir en un subdirectorio especifico del paquete de %{_libexecdir}, como por ejemplo %{_libexecdir}/%{name}.

/run

Algunos servicios del sistema posiblemente necesiten guardar datos variables del tiempo de ejecución antes de que /var/run este montado. Actualmente, muchos programas están abusando de /dev para este propósito. Para hacer esto algunas pocas distribuciones han hecho hacks elaborados para usar /var/run aún antes de que el propio /var este montado. Sin embargo esto es mucho menos que ideal. Varias de las distribuciones más importantes se han comprometido en soportar el uso de /run para este propósito.

Por ahora, las aplicaciones pueden utilizar /run o /var/run casi de manera intercambiable. /run DEBE ser usado cuando la aplicación pueda ser iniciada durante el proceso de inicio antes de que /var pueda ser montada.

[|Tiquete FHS para /run]

Binarios en /bin y /sbin

Los binarios localizados en /bin y /sbin no deben depender de librerías guardadas en /usr/lib (o /usr/lib64). Binarios que dependan de librerías en /usr/lib* deben quedarse en /usr/bin o /usr/sbin.

Uso de rpmlint

Ejecute rmplint en binarios y código fuente de rpms para examinarlos por errores comunes y arreglarlos (al menos que rpmlint este equivocado, que también puede pasar). Si usted no entiende la salida del rpmlint, el switch -i puede ser usado para obtener una descripción de la mayoría de los errores y alertas. Tenga en cuenta que rpmlint realiza comprobaciones adicionales si se le da el nombre del paquete instalado. Por ejemplo,yum install foo-1.0-1.f20.x86_64.rpm; rpmlint foo llevará a cabo un conjunto de pruebas en el paquete foo que en rpmlint foo-1.0-1.f20.x86_64.rpm no puede. El paquete rpmlint está disponible en los repositorios de Fedora.

Errores de Rpmlint

Rpmlint tiene la habilidad de hacer mucho ruido cuando corre, aún en un paquete perfectamente válido. Esta sección existe para ayudarlos a descifrar los mensajes para que puedan hacer los arreglos según sea necesario.

• E: foo-package no-packager-tar: Este error ocurre porque no hay un valor definido en Packager: en el archivo de especificaciones. En Fedora, nosotros no usamos la etiqueta Packager:, así que pueden ignorar este error.
• E: foo-package no-signature: Este error ocurre porque su paquete no está firmado. Como Fedora no guarda SRPMS en CSV (Solo los archivos adentro de ellos), usted no necesita firmar su paquete y puede ignorar el error.
• W: foo-package summary-ended-with-dot Resumen de mi paquete: Este error ocurre porque la entrada Summary: en su archivo de especificaciones termina con un punto. Solo deshagace del punto al final de la línea.
• E: foo-package wrong-script-end-of-line-encoding /ruta/a/algunarchivo: Este error ocurre porque una línea de DOS está en un archivo. Arreglelo en la sección %prep con sed: sed -i 's/\r//' src/algunarchivo o dos2unix.
• E: foo-package invalid-lc-messages-dir /usr/share/locale/xx_XX/LC_MESSAGES/foo.mo: Este es un error falso-positivo común. Usualmente debería ser ignorado.

Bitácora de Cambios (Changelogs)

Cada vez que haga cambios, es decir, cada vez que se incremente el EVR de un paquete, agregue una entrada de cambios. Esto es importante no sólo para tener una idea sobre la historia de un paquete, sino que también permitirá a los usuarios, compañeros empaquetadores, y la gente de control de calidad identificar con facilidad los cambios que se realicen.

Si algún cambio en particular esta relacionado a error Bugzilla, incluya el ID del error en la bitácora de cambio para fácil referencia, ejemplo:

* Wed Jun 14 2003 Joe Packager <joe at gmail.com> - 1.0-2
- Archivo README añadido (#42).

Usted debe usar uno de los formatos siguientes:

* Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> - 0.6-4
- Corregir la sintaxis del enlace. 

* Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> 0.6-4
- Corregir la sintaxis del enlace. 

* Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com>
- 0.6-4
- Corregir la sintaxis del enlace. 

Las entradas en la bitácora de cambios debería proveer un breve resumen de los cambios hechos en los paquetes entre las versiones, la actualización a una nueva versión, se añade un parche, añadir otras especificaciones, nota de los errores arreglados y CVE de haber alguno. Simplemente nunca deben tener una copia entera de la fuentes del archivo de bitácora. La intención es de darle al usuario una idea de lo que cambio en un paquete sin abrumarlo con detalles técnicos. Enlaces con otros archivos de bitácora pueden añadirse para aquellos que requieren de más información.