Packaging talk:Guidelines/es

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 del 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 esta 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

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 asi, posiblemente sea un programa binario.
 * Contiene una extensión .so, so.#, o .so.#.#.#? si es asi, es probable que sea una librería de programas.
 * Si esta 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
 * 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 contengas estos archivos. Ver: Packaging:SourceURL

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 espeficiaciones de Fedora no es el lugar para entradas de Concurso de Código Ofuscado.

Escribiendo un paquete desde Cero
Cuándo estas 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 esta 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 esta 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 soportarlas todas 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. Cada arquitectura mencionada en  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  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.

Hay excepciones notables para la guía libexecdir (cómo se especifica en Código Estándar GNU),  (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 paquequetes rpm de Fedora incluyen un macro para libexecdir,. Es altamente recomendable que los Empaquetadores guarden los archivos libexecdir en un subdirectorio especifico del paquete de, como por ejemplo.

/run
Algunos servicios del sistema posiblemente necesiten guardar datos variables del tiempo de ejecución antes de que  este montado. Actualmente, muchos programas están abusando de  para este propósito. Para hacer esto algunas pocas distribuciones han hecho hacks elaborados para usar  aún antes de que el propio   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  para este propósito.

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

Binarios en /bin y /sbin
Los binarios localizados en /bin y /sbin no deben depender de librerias 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  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, llevará a cabo un conjunto de pruebas en el paquete foo que en   no puede. El paquete rpmlint esta 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 valido. Esta sección existe para ayudarlos a descifrar los mensajes para que puedan hacer los arreglos según sea necesario.


 * : Este error ocurre porque no hay un valor definido en  en el archivo de especificaciones. En Fedora, nosotros no usamos la etiqueta , asi que pueden ignorar este error.
 * : Este error ocurre porque su paquete no está firmado. Como Fedora no guarda SRPMS en CSV (Solo los archivos adentros de ellos), usted no necesita firmar su paquete y puede ignorar el error.
 * : Este error ocurre porque la entrada  en su archivo de especificaciones termina con un punto. Solo deshagace del punto al final de la línea.
 * : Este error ocurre porque una linea de DOS está en un archivo. Arreglelo en la sección %prep con sed:  o.


 * : 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:

- Archivo README añadido (#42).
 * Wed Jun 14 2003 Joe Packager  - 1.0-2

Usted debe usar uno de los formatos siguientes:

- Corregir la sintaxis del enlace.
 * Fri Jun 23 2006 Jesse Keating  - 0.6-4

- Corregir la sintaxis del enlace.
 * Fri Jun 23 2006 Jesse Keating  0.6-4

- 0.6-4 - Corregir la sintaxis del enlace.
 * Fri Jun 23 2006 Jesse Keating 

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.