Nota: La página original es más nueva que esta traducción.
Estados de Wanna-build: una explicación
Esta página intenta explicar lo que significa cada estado de
wanna-build y qué le pasará al paquete cuando esté en ese estado.
El público al que va destinada son los responsables de los paquetes de
Debian que intentan entender por qué su paquete ha sido o no compilado
para una arquitectura específica. También se da una explicación
de los distintos resultados del registro que se pueden obtener.
Finalmente, está disponible una versión
del diagrama de flujo entre los estados de wanna-build, pero tenga
en cuenta que no habla de todo lo que se menciona en este documento.
Estados de wanna-build
Para cada arquitectura a la que Debian da soporte, hay una base de datos de
wanna-build instalada en buildd.debian.org, con todos los paquetes y su
estado de compilación actual. Hay 7 estados: needs-build,
building, uploaded, dep-wait,
failed, not-for-us, y
installed.
Sus significados son los siguientes:
- needs-build
- Un paquete marcado needs-build ha visto que su
responsable ha enviado una nueva versión, pero para una
arquitectura diferente de la arquitectura para la que es
esta base de datos de wanna-build; así que necesita que se
recompile. Si el estado es needs-build, no le
ha escogido un autocompilador todavía, pero lo hará (una vez
uno esté disponible en un momento en el que el paquete específico
esté cerca del principio de la lista). La gente comúnmente dice
que
un paquete está en la cola para la recompilación
cuando
hablan sobre un paquete en estado needs-build.
Puede ser interesante darse cuenta de que la cola needs-build
no es una cola FIFO
; más bien, el orden usado se basa en los
siguientes criterios:
- Paquetes con estados previos de compilación: a los paquetes
que se han compilado previamente se les da prioridad sobre los
paquetes nuevos.
- prioridades (los paquetes con prioridad required se
compilan antes que los paquetes con prioridad extra)
- La sección en que esté un paquete. Este orden está basado en
qué paquetes se consideran más importantes; e.g., la sección
games se compila más tarde que la sección base,
y la sección libs se compila antes que devel.
- en orden
ASCIIbético
en el nombre del paquete.
Adicionalmente, bajo ciertas condiciones, puede suceder que un
buildd no tome paquetes del principio de la cola; por ejemplo,
cuando un buildd no puede encontrar las fuentes de un paquete dado,
lo pondrá de nuevo en la cola (donde ocupará de nuevo
su posición anterior, esto es, la cabeza de la cola), pero ignorará
el paquete durante unas pocas horas. Otro ejemplo donde puede
suceder esto es cuando una arquitectura tiene autocompiladores
múltiples; en ese caso, los adaptadores a arquitecturas pueden
elegir compilar los paquetes más grandes en sus autocompiladores
más rápidos, y dejar los más pequeños para las máquinas más lentas.
Un buildd teóricamente también puede pedir explícitamente un orden
de secciones diferente, pero no se hace normalmente.
Podría haber otras situaciones donde el orden de la cola parezca
que se ignora; pero dese cuenta que todas son excepciones.
- building
- Un paquete se marca building desde el momento en
que un autocompilador lo coja del principio de la cola de
wanna-build hasta el momento en que el administrador del
autocompilador contesta al registro. Como los paquetes no se
cogen uno a uno, esto quiere decir que un paquete puede estar
(y normalmente lo está) marcado como building antes de
que la compilación haya comenzado en realidad; sin embargo,
como buildd compila paquetes en su cola local según una cola
FIFO, no debería tomar demasiado. También tenga en cuenta
que el estado del paquete no se modifica una
vez que se complete la compilación, sino cuando el administrador
del autocompilador venga a responder al registro.
- uploaded
- Cuando un intento de compilación es satisfactorio,
se envía un registro de la compilación al administrador y a
buildd.debian.org. El responsable del autocompilador firma
el archivo .changes que está incluido dentro del registro
de compilación, y lo envía al autocompilador. Como
consecuencia, el autocompilador envía el paquete y pone su
estado como uploaded. Como tal, un paquete se puede
encontrar en la cola de entrada (en cualquier sitio).
Un autocompilador no tocará más un paquete una vez que su
estado sea uploaded, al menos no hasta el siguiente
envío o hasta que algún responsable de adaptaciones a otras
arquitecturas modifique manualmente el estado del paquete.
- dep-wait
- Cuando un paquete falla debido a que no se encuentran
dependencias en el momento de la compilación, el responsable del
autocompilador enviará un correo al autocompilador, dándole
instrucciones para quitar las fuentes del paquete y marcarlo como
dep-wait esperando las dependencias de compilación no
encontradas. Un paquete es ese estado, automáticamente,
sin intervención humana, se marcará como needs-build una vez
dichas dependencias estén disponibles.
Originariamente, un paquete tenía que ver un intento de compilación
antes de que el responsable lo pusiera manualmente en estado
dep-wait. Sin embargo, en agosto de 2005 se añadió algún
código a wanna-build que hará que un paquete se mueva del estado
installed directamente al estado
dep-wait, si eso es lo apropiado.
Hay dos casos específicos en los que puede suceder que un paquete
se marque como dep-wait para siempre; estas son cuando sucede un
error de mecanografía especificando las dependencias de dep-wait
(de forma que un paquete se marca como que está esperando una dependencia
de un paquete que no existe ni existirá) y cuando se declara una
dependencia en tiempo de compilación en un paquete que está
marcado como not-for-us, o que está en la lista
packages-arch-specific.
Como último ejemplo, considere tres paquetes: un paquete
foo, que existe sólo para i386; un paquete
bar, que existe sólo para m68k (y que aproximadamente
desarrolla la misma función); y un paquete baz, que se puede
compilar con uno de ellos, foo o bar. El
responsable del paquete baz olvida añadir bar
a las dependencias de compilación, y lo añade cuando se le
avisa de que baz está en dep-wait esperando un
inexistente foo para m68k, entonces el estado
dep-wait para m68k lo tendrán que cambiar
manualmente los responsables de m68k.
- failed
- Si un intento de compilación falló, el responsable del
autocompilador decide si realmente es un fallo que no se
debería reintentar, y el paquete se marca como failed.
Un paquete no dejará este estado hasta que un responsable decida
que debería hacerlo, o hasta que una nueva versión esté
disponible. Sin embargo, cuando una nueva versión de un paquete
que se marcó como failed en la versión anterior,
el autocompilador preguntará a su administrador si se debe o no
reintentar compilarlo; esto es así para que los paquetes que
obviamente fallarán de nuevo no hagan perder el tiempo a
buildd. Aunque descartar un paquete antes de intentar compilarlo
apenas alguna vez es la manera correcta de hacerlo,
la opción está disponible para el administrador del autocompilador.
Dese cuenta de que un paquetenunca se marcará como
failed sin intervención humana.
- not-for-us
- Ciertos paquetes concretos son específicos de arquitecturas; por
ejemplo, lilo, un gestor de arranque para i386, no se
debería recompilar para alpha, m68k, o s390. Sin embargo,
wanna-build no mira en el archivo de control de un paquete
cuando crea su base de datos; solo el nombre del paquete y sección,
el estado anterior de compilación, y su prioridad. De esta forma, al enviar por primera
vez un paquete específico de una arquitectura que no se debería
compilación para otras, no obstante se intenta (pero
falla incluso antes de que se descarguen y/o instalen las
dependencias del momento de la compilación)
Ya que los autocompiladores no deberían perder tiempo intentado
compilar paquetes que no se necesitan para su arquitectura, se
necesita una manera de listar los paquetes para los que no es
necesario ni si quiera un intento de compilación. La primera
solución a este problema fue not-for-us; sin embargo, como
eso es difícil de mantener, not-for-us está desaprobado
hoy en día; los responsables de los autocompiladores deberían usar
en su lugar packages-arch-specific, que es una lista de
paquetes específicos para una o más arquitecturas en lugar de un
estado de wanna-build.
Un paquete en not-for-us o
packages-arch-specific no dejará este
estado automáticamente; si su paquete excluye específicamente una
arquitectura dada previamente, pero ahora incluye más arquitecturas,
se debería reintroducir en la cola manualmente.
Si se llega a encontrar en la posición de tener que preguntar qué sucede con esto,
puede hacerlo preguntando al mantenedor de buildd pertinente. Se les puede localizar en $arch@buildd.debian.org.
- installed
- Como sugiere el nombre, un paquete marcado como installed
está compilado para la arquitectura para la que es la base de datos
de wanna-build. Antes de la publicación de Woody, el estado de
un paquete cambiaba de uploaded a installed tras
la ejecución diaria de katie. Con la implementación de Accepted-autobuild,
sin embargo, esto ya no es así; ahora, un paquete pasa del estado
uploaded a installed cuando se acepta en el
repositorio. Esto significa que un paquete normalmente se marca
como installed tras una media de 15 minutos.
Además de estos siete estados, wanna-build también
reconoce dos -estados eliminados, que en realidad son casos excepcionales.
Estos dos estados son dep-wait-removed y
failed-removed. Están relacionados con sus estados simples
de la siguiente manera: cuando un paquete en estado failed o
dep-wait no aparece en un nuevo archivo Packages
que se le pasa a wanna-build – cuando parece que ha
sido borrado – la información sobre ese paquete no se desecha,
ya que podría ser que el paquete no apareciese por un error temporal,
o que esté borrado temporalmente por alguna razón (pero que reaparecerá
en el repositorio, pasado un tiempo). En vez de eso, en tal caso, un
paquete se mueve al estado -removed, así la información sobre
porqué falló o qué está esperando se puede retener. El paquete
reaparecería en el siguiente archivo Packages que se le pasa a
wanna-build, y se moverá de nuevo de failed-removed a
failed, o de dep-wait-removed a dep-wait
antes de seguir el proceso.
No es posible acceder a la base de datos de wanna-build directamente;
esta base de datos está instalada en ftp-master.debian.org, que es
un servidor restringido, y solo los autocompiladores tienen una llave
ssh que les permite acceder a la base de datos de wanna-build de su
arquitectura. Este ha sido el caso incluso antes de que ftp-master
fuese restringido; como wanna-build hace un bloqueo a nivel de base
de datos cuando accede, incluso solo para lectura, de los datos, tiene
que estar en el grupo adecuado (wb-<arch>) para poder acceder
directamente a la base de datos de wanna-build.
Dicho eso, puede ver en qué estado está un paquete yendo a la
página de estadísticas
de Debian, excepto si está en estado installed
(bueno, no puede a menos que no le moleste escarbar en los archivos
"<arch>-all.txt" de varios megabytes...).
Los resultados del registro de compilación
Cuando sbuild compila un paquete (el componente de buildd
que hace la compilación en realidad), se envía un correo
con el registro del resultado, al administrador del
autocompilador y a logs@buildd.debian.org
(así que puede terminar en http://buildd.debian.org). El registro
que resulta de la compilación puede ser successful,
failed, given-back, o skipped.
Dese cuenta que, en la página
que muestra el registro de buildd, el prefijo maybe-
se añade, porque entre otras cosas, el hecho de que una compilación
se pueda marcar failed ahí para cosas que realmente
no son un fallo ha causado confusión en el pasado (o, de otra forma,
a veces un paquete que aparentemente se compiló satisfactoriamente
realmente está roto y hay que recompilarlo)..
El significado del registro de resultados es el siguiente:
- successful
- La compilación fue satisfactoria. Cuando el responsable
del autocompilador recibe este registro, extraerá el archivo
.changes incluido, lo firma, y lo envía de vuelta
al autocompilador, lo que hará que se envíe el paquete.
- failed
- La compilación falló. Como puede haber un gran número de razones por
las que falle, enumerarlos todos sería tedioso, así que no se
intentará hacer aquí. Si un paquete suyo se marca
(maybe-)failed, querrá leer lo de más arriba, y comprobar
su estado en wanna-build.
- given-back
- La compilación falló debido a un problema temporal con el
autocompilador; como ejemplos hay problemas de red, la
no disponibilidad de los paquetes fuentes en el actual
sources.list, poco espacio de disco, y otros.
Un paquete que es given-back se marca como
needs-build de nuevo;
como tal, será automáticamente escogido por un autocompilador
diferente una vez esté preparado.
- skipped
- En el momento entre que el paquete es escogido por un
autocompilador y se marca como
building y el intento de compilación, se envía
una nueva versión de este paquete, o un adaptador modifica
manualmente el estado en wanna-build por otra razón. Cuando
se hace eso, se envía un correo al autocompilador, que
marcará el paquete como que no va a ser compilado; sbuild
ve esto, y se saltará la compilación (aunque se envía un
registro con ese resultado, describiendo el hecho que ocasionó
esto).
Para ilustrar lo de más arriba, también hemos proporcionado una versión de diagrama de flujo de este procedimiento.
De nuevo, tenga en cuenta que no contiene todo lo mencionado en este documento.
