[LCFC] wml://devel/buildd/index.wml
Hola
He incorporado las correcciones de Héctor (¡gracias!).
Saludos
Laura Arjona
#use wml::debian::template title="Red autocompiladora" BARETITLE="true"
#use wml::debian::translation-check translation="1.25"
<p>La red autocompiladora es un desarrollo de Debian que gestiona las
compilaciones de paquetes para
todas las arquitecturas <a href="$(HOME)/ports/">en las que se puede
utilizar actualmente
Debian</a>. Esta red está constituida por varias máquinas que usan
un paquete de software específico denominado <em>buildd</em> para coger
los paquetes del repositorio de Debian y reconstruirlos para la
arquitectura que se requiera.</p>
<h2>¿Por qué se necesita la red autocompiladora?</h2>
<p>La distribución Debian soporta <a href="$(HOME)/ports/">en realidad
unas pocas arquitecturas</a>, pero los responsables de los paquetes
generalmente solo compilan versiones binarias para una sola arquitectura
(en general i386 o amd64). Las otras compilaciones se producen automáticamente,
asegurando que cada paquete sólo se compila una vez. Los fallos se registran en
la base de datos de autocompilación.</p>
<p>
En el momento que empezó Debian/m68k (la primera adaptación distinta de
la arquitectura Intel), los desarrolladores tenían que vigilar cuándo había
nuevas versiones y recompilarlas si querían permanecer actualizados con la
distribución de Intel. Todo esto se hacía manualmente: los desarrolladores
miraban los nuevos paquetes en la lista de correo de envíos y cogían algunos de ellos para
construirlos. La coordinación para que ningún paquete se construya dos
veces por personas distintas se hacía anunciándolo en una lista de correo.
Es obvio que este procedimiento es propenso al error y consume mucho tiempo.
Ésta fue, sin embargo, la forma usual de mantener las distribuciones
Debian actualizadas durante mucho tiempo.
</p>
<p>
El demonio de construcción del sistema automatiza la mayor parte de
este proceso. Consiste en un conjunto de guiones (escritos en Perl
y Python) que se han mejorado con el tiempo para ayudar a los que hacen
adaptaciones
con varias tareas. Finalmente han evolucionado en un sistema que puede
mantener las distribuciones no i386 de Debian actualizadas casi
automáticamente. Las actualizaciones de seguridad se compilan en el mismo
conjunto de máquinas para asegurar su disponibilidad a tiempo.
</p>
<h2>¿Como funciona buildd?</h2>
<p><em>Buildd</em> es el nombre que se da normalmente al software que
utiliza la red autocompiladora, pero en realidad se compone
de diferentes partes:</p>
<dl>
<dt>wanna-build</dt>
<dd>
una herramienta que ayuda a coordinar la (re)construcción de paquetes a
través de una base de datos que mantiene una lista de paquetes y su estado.
Hay una base de datos central por arquitectura que almacena los estados,
versiones, y alguna otra información de los paquetes. Se alimenta de los
ficheros de fuentes y de paquetes obtenidos de los distintos archivos de paquetes
que tiene Debian (por ej. ftp-master y security-master).
</dd>
<dt><a href="http://svn.cyberhqz.com/svn/wanna-build/";>buildd</a></dt>
<dd>
un demonio que comprueba periódicamente la base de datos mantenida por
<em>wanna-build</em> y llama a <em>sbuild</em> para construir los paquetes.
Una vez se aprueba un registro de compilación por el administrador de
buildd el demonio envía el paquete al archivo apropiado.
</dd>
<dt><a href="http://packages.debian.org/sbuild";>sbuild</a></dt>
<dd>
es responsable de la compilación real de los paquetes en entornos
enjaulados aislados. Se asegura que las dependencias fuente están instaladas
en el chroot antes de compilar y después llama a las herramientas estándar de
Debian para arrancar el proceso de compilación. Los registros de la compilación
se envían a la <a href="http://buildd.debian.org";>base de datos de registros de
compilación</a>.
</dd>
</dl>
<p>Todas estas partes <a href="operation">operan</a>
juntas para hacer que la red constructora funcione adecuadamente.</p>
<h2>¿Qué tiene que hacer un desarrollador de Debian?</h2>
<p>Realmente, un desarrollador medio de Debian no necesita usar
explícitamente la red buildd. Cuando envíe un paquete al repositorio
(binario compilado para una determinada arquitectura) se añadirá a
la base de datos para todas las arquitecturas (en estado <em>Needs-Build</em>,
necesita compilación). Las máquinas de construcción pedirán a la base de datos
de construcciones paquetes en este estado, y de forma rutinaria tomarán los
paquetes de esa lista. Ésta se encuentra priorizada por el estado previo de compilación
(que puede ser <em>out-of-date</em>, des-actualizado, o <em>uncompiled</em>,
sin compilar), prioridad, sección y finalmente nombre del paquete.
Adicionalmente, para impedir que algunos paquetes se queden sin recursos al
final de la cola, se ajustan las prioridades de forma dinámica con un tiempo
incremental de espera en la cola.</p>
<p>Si la construcción del paquete es satisfactoria para todas las
arquitecturas, el responsable no tendrá que hacer nada. Todos esos
paquetes binarios se enviarán al archivo correspondiente. Si la construcción
no es satisfactoria el paquete entrará en unos estados especiales:
<em>Build-Attempted</em> para fallos de compilación que no han sido revisados,
<em>Failed</em> para revisión y fallos reportados en los paquetes o
<em>Dep-Wait</em>, si las dependencias específicas que tiene para su
construcción no están disponibles.
Los administradores de la autocompilación revisarán los paquetes cuya
construcción falla e informarán al responsable, normalmente, abriendo un
error en el sistema de seguimiento de fallos.</p>
<p>A veces un paquete se toma un largo período de tiempo para
construirlo para una arquitectura dada y eso bloquea la entrada del
paquete en <a href="$(HOME)/devel/testing">testing</a>.
Si un paquete impide una transición las prioridades se ajustan
habitualmente bajo petición del equipo responsable de la Publicación de Debian.
No se aceptarán otras peticiones para acelerar la construcción de un paquete ya
que el tiempo incremental en la cola de compilación dará lugar a un prioridad
de compilación mayor de forma automática.</p>
<p>Puede comprobar el estado de los diferentes intentos de buildd
con los paquetes que pertenecen a un responsable dado revisando los
<a href="https://buildd.debian.org/status/";>registros de buildd</a>.
Estos registros también están enlazados desde la Panorámica de Responsables
de Paquetes.</p>
<p>Para más información sobre los diferentes estados en que puede
estar un paquete, por favor lea los
<a href="wanna-build-states">estados de wanna-build</a>.</p>
<h2>¿Dónde puedo encontrar información adicional?</h2>
<p>Por supuesto, la documentación y el código fuente disponible para las
distintas herramientas son la mejor manera de averiguar como funciona la red buildd.
Adicionalmente la sección
<a href="$(HOME)/doc/manuals/developers-reference/pkgs#porting">\
Adaptar y ser adaptado</a> de la
<a href="$(HOME)/doc/manuals/developers-reference/">Referencia de
desarrolladores de Debian</a> proporciona información complementaria
sobre cómo funciona y también algo de información sobre
<a href="$(HOME)/doc/manuals/developers-reference/tools#tools-builders">\
constructores de paquetes</a> y
<a href="$(HOME)/doc/manuals/developers-reference/tools#tools-porting">\
herramientas de adaptación</a> que están involucrados en el proceso de
configuración y mantenimiento de la red buildd.</p>
<p>Hay algunas estadísticas disponibles de la red autocompiladora en la
<a href="http://buildd.debian.org/stats/";>página de estadísticas de buildd</a>.</p>
<h2>¿Cómo puedo configurar mi propio nodo autocompilador?</h2>
<p>Hay varias razones por las que un desarrollador (o usuario)
puede querer configurar y ejecutar un autocompilador:</p>
<ul>
<li>Ayudar en el desarrollo de una adaptación para una arquitectura dada
(cuando se necesitan los autocompiladores)</li>
<li>Evaluar el impacto de una optimización del compilador o parche
recompilando un gran subconjunto de paquetes.</li>
<li>Ejecutar herramientas que analicen los paquetes buscando errores
conocidos y necesitan ejecutarse sobre paquetes compilados. Esto incluso se
necesita cuando se hagan análisis del código fuente, por ejemplo, como un
arreglo temporal de los paquetes utilizando <tt>dpatch</tt>.</li>
</ul>
<p>Puede leer más información sobre cómo puede <a
href="http://buildd.debian.org/docs/buildd-setup.txt";>configurar un
autocompilador</a>.</p>
<h2>Contactar con los administradores de buildd</h2>
<p>Se puede contactar con los administradores de los buildds de una
arquitectura en particular en <email arquitectura@buildd.debian.org>, por
ejemplo <email i386@buildd.debian.org>.</p>
<hrline />
<p><small>Esta introducción a la red autocompiladora se escribió con
aportaciones y partes proporcionadas de Roman Hodek,
Christian T. Steigies, Wouter Verhelst, Andreas Barth, Francesco Paolo
Lovergine, Javier Fernández-Sanguino y Philipp Kern.</small></p>
Reply to: