Product SiteDocumentation Site

15.4. Cómo convertirse en un encargado de paquetes

15.4.1. Aprendizaje de creación de paquetes

Creating a quality Debian package is not always a simple task, and becoming a package maintainer takes some learning, both with theory and practice in technical and legal matters. It is not a simple matter of building and installing software; rather, the bulk of the complexity comes from understanding the problems and conflicts, and more generally the interactions, with the myriad of other packages available.

15.4.1.1. Reglas

Un paquete Debian debe cumplir con las reglas precisas agrupadas en la normativa Debian, y todo encargado de paquetes debe conocerlas. No hay necesidad de saberlas de memoria, sino saber que existen y consultarlas cuando se enfrente ante alternativas no triviales. Todo encargado Debian ha cometido errores por no conocer alguna regla, pero esto no es un gran problema siempre y cuando se corrija cuando un usuario informe del error como (lo que sucede bastante rápido gracias a usuarios avanzados). El campo Standards-Version en debian/control especifica la versión de la política de Debian a la que se adhiere un paquete. Los desarrolladores deberían adherirse a la última versión de la política de Debian

15.4.1.2. Procedimientos

Debian no es una simple colección de paquetes individuales. El trabajo de empaquetado de todos es parte de un proyecto colectivo; ser un desarrollador Debian incluye saber cómo funciona el proyecto Debian como un todo. Todo desarrollador, tarde o temprano, interactuará con otros. La referencia de desarrolladores de Debian («Debian Developer's Reference», en el paquete developers-reference) resume lo que todo desarrollador debe saber para poder interactuar de la mejor forma posible con los varios equipos dentro del proyecto y para poder aprovechar al máximo los recursos disponibles. Este documento también enumera una serie de deberes que se espera cumpla un desarrollador.

15.4.1.3. Herramientas

Muchas herramientas ayudan a los encargados de paquetes con su trabajo. Esta sección las describe rápidamente, pero no provee todos sus detalles, ya que cada una de ellas cuenta con su propia documentación.
15.4.1.3.1. devscripts
El paquete devscripts contiene muchos programa que ayudan en un gran espectro del trabajo de un desarrollador Debian:
  • debuild permite generar un paquete (con dpkg-buildpackage) y ejecutar lintian para verificar si cumple con la normativa Debian luego.
  • debclean limpia un paquete fuente luego que se generó un paquete binario.
  • dch permite editar rápida y fácilmente el archivo debian/changelog en un paquete fuente.
  • uscan verifica si el autor original publicó una nueva versión de un software; esto necesita un archivo debian/watch con una descripción de la ubicación de dichas publicaciones.
  • debi permite instalar (con dpkg -i) el paquete Debian que acaba de generar sin necesidad de introducir su nombre y ruta completos.
  • De forma similar, debc le permite escanear el contenido de un paquete generado recientemente (con dpkg -c) sin tener que ingresar su nombre y ruta completos.
  • bts controla el sistema de seguimiento de errores desde la consola; este programa genera los correos apropiados automáticamente.
  • debrelease sube un paquete recientemente generado a un servidor remoto sin tener que ingresar el nombre y ruta completos del archivo .changes relacionado.
  • debsign firma los archivos *.dsc y *.changes.
  • uupdate automatiza la creación de una nueva revisión de un paquete cuando se publicó una nueva versión del software original.
Todos los comandos mencionados están documentados en sus respectivas páginas de manual. Además, el ususario los puede configurar en un archivo: ~/.devscripts.
15.4.1.3.2. debhelper y dh-make
Debhelper es un conjunto de scripts que facilitan la creación de paquetes que cumplan la normativa; se ejecutan estos scripts desde debian/rules. Debhelper ha sido ampliamente adoptado en Debian, como muestra el hecho de que sea usado en la mayoría de los paquetes de Debian oficiales. Todos los programas que contiene tienen un prefijo dh_. Cada uno de ellos está documentado en una página del manual. Los diferentes niveles de compatibilidad y las opciones comunes se describen en debhelper(7).
El script dh_make (en el paquete dh-make) crea los archivos necesarios para generar un paquete Debian en un directorio que contiene inicialmente las fuentes de un software. Como puede adivinar del nombre del programa, los archivos generados utilizan debhelper de forma predeterminada.
15.4.1.3.3. lintian
Esta herramienta es una de las más importantes: es el verificador de paquetes Debian. Está basado en un gran conjunto de pruebas creadas a partir de la normativa Debian, y detecta rápida y automáticamente muchos errores que pueden corregirse antes de publicar los paquetes.
Esta herramienta es sólo una ayuda y a veces está equivocada (por ejemplo, como la normativa Debian cambia con el tiempo, lintian a veces está desactualizado). No es exhaustiva: no debe interpretar el no obtener ningún error Lintian como prueba de que el paquete es perfecto; como máximo, éste evita los errores más comunes.
15.4.1.3.4. piuparts
Esta es otra herramienta importante: automatiza la instalación, actualización, eliminación y purga de un paquete (en un entorno aislado) y revisa que ninguna de estas operaciones genere un error. Puede ayudar a detectar dependencias faltantes y también detecta cuando un archivo no elimina archivos que debería luego de ser purgado.
15.4.1.3.5. autopkgtest
autopkgtest ejecuta pruebas en paquetes binarios, usando las pruebas proporcionadas en el paquete fuente debian/tests/. Varios comandos permiten la fácil creación de entornos de prueba virtuales o chrooted.
15.4.1.3.6. reprotest
reprotest compila el mismo código fuente dos veces en diferentes entornos, y luego comprueba si hay diferencias en los binarios producidos en cada compilación. Si se encuentra alguna, la instrucción diffoscope (si no está disponible, diff) se usa para mostrarlos en detalle para un posterior análisis.
15.4.1.3.7. dupload y dput
Los comandos dupload y dput permiten subir un paquete Debian a un servidor (posiblemente remoto). Esto permite a los desarrolladores publicar sus paquetes en el servidor Debian principal (ftp-master.debian.org) para que se pueda integrar en el repositorio y ser distribuido por sus réplicas. Estos comandos toman como parámetros un archivo .changes y deducen los demás archivos relevantes de su contenido.
15.4.1.3.8. git-buildpackage y dgit
El proyecto ha estado utilizando varios sistemas de control de versiones a lo largo de los años para almacenar los esfuerzos de empaquetado o el código fuente del paquete, o permitir el mantenimiento colaborativo de paquetes. En un intento de unificar los sistemas y esfuerzos, finalmente se decidió en 2017 mover (casi) todas los paquetes fuentes a Git (CULTURA «Git») a una instancia de Gitlab llamada salsa.debian.org.
Se han desarrollado herramientas para hacer que el empaquetado usando Git sea más fácil para los desarrolladores de Debian. Estas permiten no solo almacenar los archivos de empaquetado en Git, sino también usar los repositorios de Git (y su historial) de proyectos de software, colocar parches aplicados a los paquetes fuentes en el historial de Git, mantener versiones de software por distribución, etc.
Uno de los paquetes más famosos es git-buildpackage. Una alternativa es dgit. Por supuesto, todavía es posible no usar ninguno de esos.
A continuación aparece un ejemplo de un archivo de configuración ~/.gbp.conf
[DEFAULT]
builder = sbuild -d bullseye --build-dep-resolver=aptitude -s --source-only-changes --build-failed-commands "%SBUILD_SHELL"
pristine-tar = true

[buildpackage]
sign-tags = true
keyid = XXXX
postbuild  = autopkgtest --user debci --apt-upgrade -s "$GBP_CHANGES_FILE" -- lxc --sudo autopkgtest-bullseye-amd64 
export-dir = /tmp/build-area/
notify = off

[import-orig]
filter-pristine-tar = true
sign-tags = true

[pq]
drop = true
Así construir el paquete es tan fácil como ejecutar gbp buildpackage en el árbol de Git. Comenzará la construcción de un paquete en un chroot Bullseye de Debian usando sbuild. Cuando la construcción tiene éxito, los archivos creados se comprueban ejecutando el autopkgtest-testsuite (si está definido). Todas las opciones se explican en gbp.conf(5) y /etc/git-buildpackage/gbp.conf.
Todas las herramientas mencionadas hasta ahora se han incluido en el proceso de integración continua (CI) en la instancia salsa.debian.org también en:

15.4.2. Proceso de aceptación

Convertirse en un "desarrollador Debian" no es una simple cuestión administrativa. El proceso tiene varios pasos, y se parece tanto a una iniciación como a un proceso de selección. En cualquier caso, está formalizado y bien documentado, por lo que cualquiera puede seguir su progreso en el sitio web dedicado al proceso para nuevos miembros.

15.4.2.1. Prerrequisitos

Se espera que todos los candidatos tengan un conocimiento práctico del idioma inglés. Esto es necesario en todos los niveles: por supuesto, para la comunicación inicial con el examinador pero también luego, ya que el inglés es el idioma de preferencia para la mayoría de la documentación; además los usuarios de paquetes se comunicarán en inglés al reportar errores y esperarán respuestas en el mismo idioma.
El otro prerequisito tiene que ver con la motivación. Ser un desarrollador Debian es un proceso que sólo tiene sentido si el candidato sabe que su interés en Debian durará muchos meses. El proceso de aceptación en sí puede durar varios meses, y Debian necesita desarrolladores a largo plazo; se necesita mantener permanentemente cada paquete y no sólo subirlos y ya.

15.4.2.2. Registración

El primer paso (real) consiste en encontrar un patrocinador («sponsor») o partidario («advocate»); esto significa un desarrollador oficial dispuesto a manifestar que aceptar X sería algo bueno para Debian. Esto generalmente implica que el candidato ha participado en la comunidad y que se apreció su trabajo. Si el candidato es tímido y no promocionó su trabajo públicamente, pueden intentar convencer a un desarrollador Debian para que lo patrocine mostrándole su trabajo en privado.
Al mismo tiempo, el candidato debe generar un par de claves pública/privada con GnuPG, que deben ser firmadas por al menos dos desarrolladores Debian oficiales. La firma autentica el nombre en la llave. Efectivamente, durante una fiesta de firma de claves, cada participante debe mostrar identificación oficial (generalmente un pasaporte o documento de identidad) junto con sus identificadores de claves. Este paso confirma la relación entre la persona y las claves. Esta firma, por lo tanto, requiere encontrarse en la vida real. Si no encuentra ningún desarrollador Debian en una conferencia pública de software libre, puede buscar explícitamente desarrolladores que vivan cerca utilizando la lista en la siguiente página web como punto de partida.
Una vez que el patrocinador validó la registración en nm.debian.org, se le asigna al candidato un Gestor de aplicación («Application Manager»). El gestor de aplicación, de allí en adelante, dirigirá el proceso a través de varios pasos y validaciones predeterminados.
La primera verificación es una comprobación de identidad. Si ya tiene una clave firmada por dos desarrolladores Debian, este paso es sencillo; de lo contrario, el gestor de aplicación intentará guiarlo para buscar desarrolladores Debian cercanos y organizar una reunión y firma de claves.

15.4.2.3. Aceptación de principios

Se siguen estas formalidades administrativas por consideraciones filosóficas. El objetivo es asegurarse que el candidato entiende y acepta el contrato social y los principios detrás del Software Libre. Unirse a Debian sólo es posible si uno comparte los valores que unen a los desarrolladores actuales, como están expresados en los textos de fundación (resumidos en el Capítulo 1, El proyecto Debian).
Además, se espera que cada candidato que desee unirse a las filas de Debian conozca cómo funciona el proyecto y cómo interactuar de forma apropiada para solucionar los problemas que seguramente encontrarán con el paso del tiempo. Toda esta información generalmente está documentada en los manuales para nuevos encargados y en la referencia para desarrolladores de Debian. Debería bastar con una lectura atenta de este documento para responder las preguntas del examinador. Si las respuestas no son satisfactorias, se le informará al candidato. Tendrán que leer (nuevamente) la documentación relevante antes de intentarlo de nuevo. En aquellos casos en los que la documentación existente no contenga la respuesta apropiada para la pregunta, el candidato frecuentemente podrá llegar a la respuesta con un poco de experiencia práctica dentro de Debian o, potencialmente, discutiendo con otros desarrolladores Debian. Este mecanismo asegura que los candidatos se involucren de alguna forma en Debian antes de formar completamente parte de él. Es una normativa deliberada, por la que los candidatos que se unirán eventualmente al proyecto son integrados como otra pieza de un rompecabezas que se puede extender sin fin.
Este paso es conocido generalmente como filosofía y procedimientos (abreviado como «P&P» por «Philosophy & Procedures») en la jerga de los desarrolladores involucrados en el proceso de nuevos miembros.

15.4.2.4. Revisión de habilidades

Se debe justificar cada aplicación para convertirse en un desarrollador oficial de Debian. Convertirse en un miembro del proyecto requiere mostrar que esta posición es legítima y que facilita el trabajo del candidato para ayudar a Debian. La justificación más común es que ser desarrollador Debian facilita el mantener un paquete Debian, pero no es la única. Algunos desarrolladores se unen al proyecto para adaptar una arquitectura particular, otros desean mejorar la documentación, etc.
Este paso le ofrece al candidato la oportunidad de especificar lo que desean hacer dentro del proyecto Debian y mostrar lo que ya han hecho para ello. Debian es un proyecto pragmático y decir algo no es suficiente si las acciones no coinciden con lo que se anuncia. Frecuentemente, cuando el rol deseado dentro del proyecto está relacionado con la manutención de un paquete, se deberá validar técnicamente una primera versión del futuro paquete y deberá ser subido a los servidores Debian por un desarrollador Debian existente como patrocinador.
Finally, the examiner checks the candidate's technical (packaging) skills with a detailed questionnaire. Bad answers are not permitted, but the answer time is not limited. All the documentation is available and several attempts are allowed if the first answers are not satisfactory. This step does not intend to discriminate, but to ensure at least a modicum of knowledge common to new contributors.
En la jerga de los examinadores, se conoce a este paso como tareas y habilidades (abreviado «T&S» por «Tasks & Skills»).

15.4.2.5. Aprobación final

En el último paso, un DAM (gestor de cuentas Debian: «Debian Account Manager») revisa todo el proceso. El DAM revisará toda la información que recolectó el examinador sobre el candidato y tomará la decisión de crearle una cuenta en los servidores Debian o no. En los casos que necesite información adicional se puede demorar la creación de la cuenta. Los rechazos son bastante raros si el examinador realiza un buen trabajo siguiendo el procedimiento, pero a veces ocurren. Nunca son permanentes y el candidato es libre de intentar nuevamente luego de un tiempo.
La decisión del DAM es final y (casi) sin apelación, lo que explica porqué, en el pasado, se criticaba frecuentemente a aquellos en dicho rol .