Distribución testing de Debian

Si desea información básica, orientada al usuario, sobre la distribución en pruebas o testing, diríjase a las FAQ de Debian.

Algo que es importante que tengan en cuenta tanto los usuarios habituales como los desarrolladores de testing, es que sus actualizaciones de seguridad no son gestionadas por el equipo de seguridad. Si desea más información lea por favor las FAQ del equipo de seguridad.

Esta página cubre principalmente los aspectos de testing importantes para desarrolladores de Debian.

Cómo funciona testing

La distribución testing se genera de forma automática. Se origina partiendo de la distribución unstable mediante una serie de scripts que intentan pasar de una a otra paquetes sobre los que sea razonable pensar que carecen de fallos críticos para la publicación. Lo hacen de manera que las dependencias de los otros paquetes en testing se puedan satisfacer siempre.

Un paquete (una versión en particular) pasará a testing cuando satisfaga todos los siguientes criterios:

  1. Debe haber estado en unstable 10, 5 o 2 días, dependiendo de la urgencia marcada al enviarlo;
  2. Debe estar compilado y al día en todas las arquitecturas en las que ha sido compilado anteriormente en unstable;
  3. No debe tener fallos críticos de publicación («release-critical bugs») a menos que ya estén presentes en la versión actualmente en testing (más adelante tiene más información);
  4. Todas sus dependencias deben poder ser satisfechas bien mediante paquetes ya en testing, bien mediante el grupo de paquetes que va a ser instalado al mismo tiempo;
  5. La operación de instalar un paquete en testing no debe afectar adversamente a ningún paquete que ya esté en testing (Más adelante tiene más información).

De un paquete que satisface las tres primeras condiciones se dice que es un Candidato válido.

El script de actualización muestra el momento en que cada paquete pasará de unstable a testing. La salida es doble:

Preguntas frecuentes

¿Qué son los fallos críticos, y cómo se cuentan?

Todos los fallos de importancia alta se consideran de manera predeterminada fallos críticos a efectos de publicación; actualmente lo son: critical, grave y serious.

Se presume que tales fallos tienen cierto impacto en las posibilidades de que el paquete sea distribuido con la versión estable de Debian: en general, si un paquete tiene un fallo crítico abierto, no pasará a testing y en consecuencia no saldrá en stable.

Para el conteo de fallos de testing se consideran todos los fallos críticos que correspondan a combinaciones de paquete/versión que están disponibles en testing para una arquitectura de las que se publican.

¿Cómo puede ser que instalar un paquete en testing estropee otros paquetes?

La estructura de los archivos de distribución es tal que sólo pueden contener una versión de un paquete; un paquete se define por su nombre. Por lo tanto, cuando se instala el paquete fuente acmefoo en testing, junto con sus paquetes binarios acme-foo-bin, acme-bar-bin, libacme-foo1 y libacme-foo-dev, se elimina la versión antigua.

Sin embargo, puede que la versión anterior proporcionase un paquete binario con otro «soname» para librerías, como libacme-foo0. Borrar acmefoo eliminará libacme-foo0, lo cual dejará sin posibilidad de instalación a los paquetes que dependieran de él.

Evidentemente, esto afecta principalmente a paquetes que proporcionen conjuntos cambiantes de paquetes binarios en diferentes versiones (principalmente librerías). Sin embargo, también afecta a paquetes sobre los que haya declarados dependencias versionadas de los tipos ==, <= o <<.

Cuando el conjunto de paquetes binarios proporcionados por un paquete fuente cambia de esta manera, todos los paquetes que dependen de los antiguos paquetes binarios tendrán que ser actualizados para que dependan en su lugar de los nuevos. Como instalar tal paquete fuente en testing rompe los paquetes que dependen de él en testing, habrá que tomar algunas precauciones; todos los paquetes dependientes deben ser actualizados y preparados para ser instalados de manera que no se rompan y, una vez todo esté preparado, normalmente se precisa intervención manual del responsable de publicación o un asistente.

Si está teniendo problemas con grupos complicados de paquetes como éste, póngase en contacto con debian-devel o debian-release para pedir ayuda.

¡Aún no lo entiendo! Los scripts de testing dicen que este paquete es un candidato válido, pero sigue sin entrar en testing.

Esto suele pasar cuando de alguna manera, directa o indirecta, instalar el paquete pueda afectar a otro.

Recuerde considerar las dependencias de su paquete. Suponga que el paquete depende de libtool, o libltdlX. El paquete no entrará en testing hasta que la versión adecuada de libtool esté preparada para entrar.

A su vez, esto no sucederá hasta que la instalación de libtool no rompa las cosas que ya había en testing. En otras palabras, hasta que todos los otros paquetes que dependan de libltdlY (donde Y es una versión anterior) hayan sido recompilados, y se hayan eliminado todos los fallos críticos, etc, ninguno de estos paquetes entrará en testing.

Aquí es donde es útil la salida textual (comprimida con gzip): da pistas (aunque un poco breves) sobre los paquetes que podrían quedar malparados al añadir un candidato válido a testing (vea el Manual de referencia del Desarrollador de Debian para más detalles).

¿Por qué a veces es difícil que entren en testing paquetes Architecture: all?

Si se ha de instalar un paquete Architecture: all, se debe poder satisfacer sus dependencias en todas las arquitecturas. Si depende de un cierto paquete que sólo compila en un conjunto limitado de arquitecturas de Debian, entonces no pasará.

Sin embargo, por ahora testing ignorará la incapacidad de los paquetes Architecture: all para instalarse en arquitecturas que no sean i386. (Es un hack apestoso y no estoy contento de haberlo hecho, pero ahí está. --aj)

Mi paquete está bloqueado porque no está al día en alguna arquitectura. ¿Qué hago?

Comprueba el estado de tu paquete en la base de datos de compilaciones. Si el paquete no compila, queda marcado como failed. Examina el registro de la compilación y corrige los problemas causados por las fuentes de tu paquete.

Si compruebas que alguna arquitectura ha compilado la nueva versión del paquete, pero sigue sin aparecer en la salida del script de testing, tendrás que tener un poco más de paciencia hasta que el mantenedor del buildd respectivo ponga los ficheros en el archivo de Debian.

Si nota que algunas arquitecturas no han compilado la nueva versión del paquete, incluso aunque hayas enviado correcciones para fallos previos, es probable que se deba a que esté marcado como pendiente de dependencias (Dep-Wait). También puede ver la lista de los también llamados estados wanna-build para asegurarte.

Estos problemas se suelen corregir por sí mismos, pero si lleva esperando mucho tiempo (digamos dos semanas, o más), indíqueselo al mantenedor del buildd respectivo si su dirección está documentada en la página web de adaptaciones, o en la lista de correo de esa adaptación.

¿Hay alguna excepción? Estoy seguro de que acmefoo entró en testing aunque no satisfacía todos los requisitos.

El release manager puede saltarse las reglas de dos maneras:

¿Podrías darme un ejemplo real y no trivial?

Aquí va uno: cuando se instala en testing el paquete fuente apache, junto con sus paquetes binarios apache, apache-common, apache-dev y apache-doc, se elimina la versión antigua.

Sin embargo, todos los paquetes de módulos de Apache dependen de apache-common (>= algo), apache-common (<< algo), de manera que este cambio rompe todas esas dependencias. Consecuentemente, se necesita recompilar todos los módulos con la nueva versión de Apache para poder actualizar testing.

Vamos a elaborarlo un poco más: después de haber actualizado en unstable todos los módulos para que funcionen con el nuevo Apache, los scripts de testing prueban apache-common y encuentran que rompe todos los módulos de Apache porque tienen la dependencia Depends: apache-common (<< la versión actual), y entonces prueban libapache-foo para encontrarse conque no se instalará porque tiene Depends: apache-common (>= la nueva versión).

Sin embargo, más tarde aplicarán una lógica diferente (a veces mediante intervención manual): ignorarán el hecho de que apache-common rompe cosas, y seguirán mirando las cosas que funciona; si después de hacer todo lo que podemos sigue sin funcionar, muy mal, pero quizá funcione. Más tarde comprobarán todos los paquetes libapache-foo aleatorios y verán que sí que funcionan.

Después de haberlo probado todo, comprueban cuántos paquetes han quedado en mal estado, y comparan para ver si es mejor o peor que la situación original y bien aceptan todo, o bien se olvidan del asunto. Se puede ver en las líneas recur: de update_output.txt.

Por ejemplo:

         recur: [foo bar] baz

básicamente quiere decir habiendo encontrado que foo y bar lo hacen mejor, ahora estoy probando baz a ver qué pasa, incluso sabiendo que rompe cosas. Las líneas de update_output.txt que empiezan con accepted indican cosas que parece que harán que la situación mejore, y las líneas skipped hacen que empeore.

¡El fichero update_output.txt es completamente ilegible!

Eso no es una pregunta. ;-)

Veamos un ejemplo:

 skipped: cln (0) (150+4)
     got: 167+0: a-40:a-33:h-49:i-45
     * i386: ginac-cint, libginac-dev

Esto significa que si cln entra en testing, ginac-cint y libginac-dev no podrán instalarse en testing en i386. Tenga en cuenta que las arquitecturas se comprueban en orden alfabético y que sólo aparecen los problemas de la primera arquitectura que los tenga (es por eso que alpha aparece tan a menudo).

La línea got incluye el número de problemas en testing en las diferentes arquitecturas (hasta la primera arquitectura en la que encuentra problemas, véase más adelante). El i-45 significa que si cln entrase en testing, quedarían 45 paquetes en i386 en estado ininstalable. Algunas entradas antes y después de cln muestran que hay 43 paquetes en ese estado en testing en i386 en ese momento.

La línea skipped: cln (0) (150+4) indica que todavía queda por mirar 150 paquetes tras éste antes de completar las comprobaciones de todos los paquetes, y que ya se ha encontrado 4 que no se planea actualizar porque romperán dependencias. El (0) es irrelevante, y puede ignorarlo.

Tenga en cuenta que se hacen diversas comprobaciones sobre todos los paquetes en cada ejecución de un script testing.

Jules Bean se encargaba al principio de juntar las preguntas y respuesta frecuentes.

Información adicional

Las siguientes páginas ofrecen información adicional sobre el estado actual de las pruebas y la migración de paquetes de inestable (unstable) a en pruebas (testing).

Puede que esté interesado en leer un viejo correo aclaratorio. Su único fallo importante es que no tiene en cuenta el package pool, porque James Troup lo implementó tras haber sido escrito esto.

El código de testing está disponible en ftp-master.

El crédito de la implementación de testing es para Anthony Towns.