Boceto del funcionamiento de la red de autocompilación

En el corazón del sistema está la base de datos de wanna-build, que mantiene un seguimiento de las versiones y estados de los paquetes. quinn-diff compara las listas de paquetes para la arquitectura requerida con la lista de paquetes fuente después de cada actualizar del archivo y añade los paquetes que necesitan recompilarse a la lista de la base de datos donde entran en el estado Needs-Build.

Todos los demonios de construcción (puede haber más de uno) solicitan regularmente a la base de datos esos paquetes y toman algunos de ellos de forma que entran en el estado Building. Por supuesto, los humanos pueden coger los paquetes, e.g. en casos especiales donde no es es posible la compilación automática. Aquí también vemos el segundo propósito de wanna-build: Asegurarse que la misma versión del paquete no se construye dos veces.

Esquema de autocompilación

Figura: Estados de los paquetes y transiciones

Si todo va bien, un paquete terminado se puede mandar más tarde, y se pondrá en estado Uploaded. Tras esto finalmente se instalará en el repositorio de Debian y así aparecerá en la lista de paquetes actualizados de esa arquitectura. Esta lista se fusionará en la base de datos, así el paquete pasará al estado Installed y permanecerá ahí hasta la próxima versión del paquete fuente.

Hay varios otros estados; incluyen: Failed es para los paquetes cuya compilación falló por errores en las fuentes, y se espera que los errores se arreglen en una versión posterior (tras informar del problema, por supuesto). Así una nueva versión entrará directamente en Needs-Build, pero con un aviso de que algo fue mal en la versión anterior. Mientras esté en este estado se guardará una descripción del error. El estado Dep-Wait se usa cuando un paquete necesita algunos otros paquetes para compilarse pero estos no están disponibles aún y se deben compilar antes. Este estado almacena una lista de los paquetes que se necesitan y puede que las versiones, y si se sabe que todos ellos van a ser instalados y el estado vuelve a Needs-Build.

Como ya hemos visto, el demonio de compilación toma los paquetes de la base de datos para compilarlos. Veámoslo un poco más de cerca: si tiene algunos paquetes que compilar, usa sbuild para el proceso de compilación real, y por cada compilación se envía un correo con el registro al responsable del demonio. Este revisa el registro y decide qué hacer con el paquete: enviarlo, ponerlo como Failed o Dep-Wait y reintentarlo, etc... Si se recibe una confirmación positiva (un archivo .changes firmado), el demonio lo mueve a un directorio de envíos, desde donde se envían todos los paquetes por una tarea del cron.

La única intervención humana en todo el proceso es mirar en el archivo de registro si no se han producido errores. Hay dos buenas razones para no automatizar más esto: Primero, a veces las construcciones acaban con un resultado «OK» pero la construcción no obstante falló por razones que son invisibles para la máquina. Y segundo, enviarlo directamente requeriría firmar automáticamente con PGP los archivos resultantes con una llave sin una frase de contraseña en la máquina de construcción. Considero que esto es una agujero de seguridad inaceptable.

El script de compilación sbuild más o menos solo llama a algunas herramientas estándar de Debian para compilar las fuentes. También ayuda con algunas de las tareas comunes y la contabilidad, así como con la instalación automática de dependencias de compilación necesarias mientras se construye el paquete.


Contenido desarrollado por Roman Hodek para el 6º International Linux-Kongress 1999, fue actualizado ligeramente para reflejar el estado actual por Philipp Kern en 2009