Hola Gracias a todos por las aportaciones. Aquí va rehecho, con la aportación de Martín y para soname lo que he hecho es ponerle comillas. Un saludo Laura Arjona
#use wml::debian::template title="Distribución <q>testing</q> de Debian" BARETITLE=true #include "$(ENGLISHDIR)/releases/info" #use wml::debian::translation-check translation="1.31"
<p>Si desea información básica, orientada al usuario, sobre la distribución <q>en pruebas</q> o <q>testing</q>, diríjase a <a href="$(DOC)/manuals/debian-faq/ch-ftparchives#s-testing">las FAQ de Debian</a>.</p> <p>Algo que es importante que tengan en cuenta tanto los usuarios habituales como los desarrolladores de testing, es que sus actualizaciones de seguridad <strong>no son gestionadas por el equipo de seguridad</strong>. Si desea más información lea por favor las <a href="../security/faq#testing">FAQ del equipo de seguridad</a>.</p> <p>Esta página cubre principalmente los aspectos de <q>testing</q> importantes para desarrolladores de Debian.</p> <h2>Cómo funciona <q>testing</q></h2> <p>La distribución <q>testing</q> se genera de forma automática. Se origina partiendo de la distribución <q>unstable</q> 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 <q>testing</q> se puedan satisfacer siempre.</p> <p>Un paquete (una versión en particular) pasará a <q>testing</q> cuando satisfaga todos los siguientes criterios:</p> <ol> <li>Debe haber estado en <q>unstable</q> 10, 5 o 2 días, dependiendo de la urgencia marcada al enviarlo;</li> <li>Debe estar compilado y al día en todas las arquitecturas en las que ha sido compilado anteriormente en <q>unstable</q>;</li> <li>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 <q>testing</q> (más adelante tiene <a href="#faq">más información</a>);</li> <li>Todas sus dependencias deben poder ser satisfechas <em>bien</em> mediante paquetes ya en <q>testing</q>, <em>bien</em> mediante el grupo de paquetes que va a ser instalado al mismo tiempo;</li> <li>La operación de instalar un paquete en <q>testing</q> no debe afectar adversamente a ningún paquete que ya esté en <q>testing</q> (Más adelante tiene <a href="#faq">más información</a>).</li> </ol> <p>De un paquete que satisface las tres primeras condiciones se dice que es un <q>Candidato válido</q>.</p> <p>El script de actualización muestra el momento en que cada paquete pasará de <q>unstable</q> a <q>testing</q>. La salida es doble:</p> <ul> <li>Las <a href="http://ftp-master.debian.org/testing/update_excuses.html";>\ excusas en la actualización</a> [<a href="http://ftp-master.debian.org/testing/update_excuses.html.gz";>comprimidas con gzip</a>]: lista de las versiones de todos los paquetes candidatos y el estado básico de su propagación a <q>testing</q>; es más corta y tiene mejor aspecto que </li> <li>La <a href="http://ftp-master.debian.org/testing/update_output.txt";>\ salida de actualización</a> [<a href="http://ftp-master.debian.org/testing/update_output.txt.gz";>comprimida con gzip</a>]: constituye la salida completa y sin tratar de los scripts de <q>testing</q> según examinan a los candidatos. </li> </ul> <h2><a name="faq">Preguntas frecuentes</a></h2> # Nota a los traductores: estos dos primeros elementos son casi los mismos que # http://www.debian.org/doc/manuals/developers-reference/pkgs#faq <h3><q>¿Qué son los fallos críticos, y cómo se cuentan?</q></h3> <p>Todos los fallos de importancia alta se consideran de manera predeterminada <em><a href="http://bugs.debian.org/release-critical/";>fallos críticos a efectos de publicación</a></em>; actualmente lo son: <strong>critical</strong>, <strong>grave</strong> y <strong>serious</strong>.</p> <p>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 <q>testing</q> y en consecuencia no saldrá en <q>stable</q>.</p> <p>Para el conteo de fallos de <q>testing</q> se consideran todos los fallos críticos que correspondan a combinaciones de <tt>paquete/versión</tt> que están disponibles en <q>testing</q> para una arquitectura de las que se publican. <h3><q>¿Cómo puede ser que instalar un paquete en <q>testing</q> estropee otros paquetes?</q></h3> <p>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 <tt>acmefoo</tt> en <q>testing</q>, junto con sus paquetes binarios <tt>acme-foo-bin</tt>, <tt>acme-bar-bin</tt>, <tt>libacme-foo1</tt> y <tt>libacme-foo-dev</tt>, se elimina la versión antigua.</p> <p>Sin embargo, puede que la versión anterior proporcionase un paquete binario con otro «soname» para librerías, como <tt>libacme-foo0</tt>. Borrar <tt>acmefoo</tt> eliminará <tt>libacme-foo0</tt>, lo cual dejará sin posibilidad de instalación a los paquetes que dependieran de él.</p> <p>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 <<.</p> <p>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 <q>testing</q> rompe los paquetes que dependen de él en <q>testing</q>, habrá que tomar algunas precauciones; todos los paquetes dependientes deben ser actualizados y preparados para ser instalados de manera que no se <q>rompan</q> y, una vez todo esté preparado, normalmente se precisa intervención manual del responsable de publicación o un asistente.</p> <p>Si está teniendo problemas con grupos complicados de paquetes como éste, póngase en contacto con debian-devel o debian-release para pedir ayuda.</p> <h3><q>¡Aún no lo entiendo! Los scripts de <q>testing</q> dicen que este paquete es un candidato válido, pero sigue sin entrar en <q>testing</q>.</q></h3> <p>Esto suele pasar cuando de alguna manera, directa o indirecta, instalar el paquete pueda afectar a otro.</p> <p>Recuerde considerar las dependencias de su paquete. Suponga que el paquete depende de libtool, o libltdl<var>X</var>. El paquete no entrará en <q>testing</q> hasta que la versión adecuada de libtool esté preparada para entrar.</p> <p>A su vez, esto no sucederá hasta que la instalación de libtool no rompa las cosas que ya había en <q>testing</q>. En otras palabras, hasta que todos los otros paquetes que dependan de libltdl<var>Y</var> (donde <var>Y</var> es una versión anterior) hayan sido recompilados, y se hayan eliminado todos los fallos críticos, etc, ninguno de estos paquetes entrará en <q>testing</q>.</p> <p>Aquí es donde es útil la <a href="http://ftp-master.debian.org/testing/update_output.txt";>\ salida textual</a> (<a href="http://ftp-master.debian.org/testing/update_output.txt.gz";>comprimida con gzip</a>): da pistas (aunque un poco breves) sobre los paquetes que podrían quedar malparados al añadir un candidato válido a <q>testing</q> (vea el <a href="$(DOC)/manuals/developers-reference/pkgs#details">\ Manual de referencia del Desarrollador de Debian para más detalles</a>). </p> <h3><q>¿Por qué a veces es difícil que entren en <q>testing</q> paquetes <kbd>Architecture: all</kbd>?</q></h3> <p>Si se ha de instalar un paquete <kbd>Architecture: all</kbd>, se debe poder satisfacer sus dependencias en <strong>todas</strong> las arquitecturas. Si depende de un cierto paquete que sólo compila en un conjunto limitado de arquitecturas de Debian, entonces no pasará.</p> <p>Sin embargo, por ahora <q>testing</q> ignorará la incapacidad de los paquetes <kbd>Architecture: all</kbd> para instalarse en arquitecturas que no sean i386. (<q>Es un hack apestoso y no estoy contento de haberlo hecho, pero ahí está.</q> --aj)</p> <h3><q>Mi paquete está bloqueado porque no está al día en alguna arquitectura. ¿Qué hago?</q></h3> <p>Comprueba el estado de tu paquete en la <a href="http://buildd.debian.org/build.php";>base de datos de compilaciones</a>. Si el paquete no compila, queda marcado como <em>failed</em>. Examina el registro de la compilación y corrige los problemas causados por las fuentes de tu paquete.</p> <p>Si compruebas que alguna arquitectura ha compilado la nueva versión del paquete, pero sigue sin aparecer en la salida del script de <q>testing</q>, 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.</p> <p>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 <q>pendiente de dependencias</q> (Dep-Wait). También puede ver la lista de los también llamados <a href="http://buildd.debian.org/stats/";>estados wanna-build</a> para asegurarte.</p> <p>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 <a href="$(HOME)/ports/">página web de adaptaciones</a>, o en la lista de correo de esa adaptación.</p> <h3><q>¿Hay alguna excepción? Estoy seguro de que <tt>acmefoo</tt> entró en <q>testing</q> aunque no satisfacía todos los requisitos.</q></h3> <p>El <q>release manager</q> puede saltarse las reglas de dos maneras:</p> <ul> <li>Puede decidir que la situación de inestabilidad causada por una nueva librería sea para mejor en lugar de para peor, y la deje entrar junto con su flotilla de dependientes.</li> <li>También puede eliminar de forma manual de <q>testing</q> paquetes que pudieran estar mal, de manera que se puedan instalar nuevas cosas.</li> </ul> <h3><q>¿Podrías darme un ejemplo real y no trivial?</q></h3> <p>Aquí va uno: cuando se instala en <q>testing</q> el paquete fuente <tt>apache</tt>, junto con sus paquetes binarios <tt>apache</tt>, <tt>apache-common</tt>, <tt>apache-dev</tt> y <tt>apache-doc</tt>, se elimina la versión antigua.</p> <p>Sin embargo, todos los paquetes de módulos de Apache dependen de <code>apache-common (>= <var>algo</var>), apache-common (<< <var>algo</var>)</code>, 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 <q>testing</q>.</p> <p>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 <q>testing</q> prueban <tt>apache-common</tt> y encuentran que rompe todos los módulos de Apache porque tienen la dependencia <code>Depends: apache-common (<< <var>la versión actual</var>)</code>, y entonces prueban <tt>libapache-<var>foo</var></tt> para encontrarse conque no se instalará porque tiene <code>Depends: apache-common (>= <var>la nueva versión</var>)</code>.</p> <p>Sin embargo, más tarde aplicarán una lógica diferente (a veces mediante intervención manual): ignorarán el hecho de que <tt>apache-common</tt> 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 <strong>quizá</strong> funcione. Más tarde comprobarán todos los paquetes <tt>libapache-<var>foo</var></tt> aleatorios y verán que sí que funcionan.</p> <p>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 <q><code>recur:</code></q> de <tt>update_output.txt</tt>.</p> <p>Por ejemplo:</p> <pre> recur: [<var>foo</var> <var>bar</var>] <var>baz</var> </pre> <p>básicamente quiere decir <q>habiendo encontrado que <var>foo</var> y <var>bar</var> lo hacen mejor, ahora estoy probando <var>baz</var> a ver qué pasa, incluso sabiendo que rompe cosas</q>. Las líneas de <tt>update_output.txt</tt> que empiezan con <q><code>accepted</code></q> indican cosas que parece que harán que la situación mejore, y las líneas <q><code>skipped</code></q> hacen que empeore.</p> <h3><q>¡El fichero <tt>update_output.txt</tt> es completamente ilegible!</q></h3> <p>Eso no es una pregunta. ;-)</p> <p>Veamos un ejemplo:</p> <pre> skipped: cln (0) (150+4) got: 167+0: a-40:a-33:h-49:i-45 * i386: ginac-cint, libginac-dev </pre> <p>Esto significa que si <tt>cln</tt> entra en <q>testing</q>, <tt>ginac-cint</tt> y <tt>libginac-dev</tt> no podrán instalarse en <q>testing</q> 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).</p> <p>La línea <q>got</q> incluye el número de problemas en <q>testing</q> en las diferentes arquitecturas (hasta la primera arquitectura en la que encuentra problemas, véase más adelante). El <q>i-45</q> significa que si <tt>cln</tt> entrase en <q>testing</q>, quedarían 45 paquetes en i386 en estado ininstalable. Algunas entradas antes y después de <tt>cln</tt> muestran que hay 43 paquetes en ese estado en <q>testing</q> en i386 en ese momento.</p> <p>La línea <q>skipped: cln (0) (150+4)</q> 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 <q>(0)</q> es irrelevante, y puede ignorarlo.</p> <p>Tenga en cuenta que se hacen diversas comprobaciones sobre todos los paquetes en cada ejecución de un script <q>testing</q>.</p> <p><em>Jules Bean se encargaba al principio de juntar las preguntas y respuesta frecuentes.</em></p> # Created: Sat Dec 8 12:44:29 GMT 2001 <h2>Información adicional</h2> <p>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). <ul> <li>Lista de paquetes binarios que están desactualizados en: <a href="http://ftp-master.debian.org/testing/testing_outdate.txt";>testing</a>, <a href="http://ftp-master.debian.org/testing/stable_outdate.txt";>stable</a> y <li>Problemas con las dependencias en <a href="http://qa.debian.org/debcheck.php?list=INDEX&dist=testing";>testing</a>, <a href="http://qa.debian.org/debcheck.php?list=INDEX&dist=stable";>stable</a> <li> Aquí tiene una sencilla <a href="http://release.debian.org/migration/";>interfaz web</a> que puede ayudarle a averiguar por que hay paquetes en pruebas que están retenidos. </ul> <p>Puede que esté interesado en leer un viejo <a href="http://lists.debian.org/debian-devel-0008/msg00906.html";>correo aclaratorio</a>. Su único fallo importante es que no tiene en cuenta el <q>package pool</q>, porque James Troup lo implementó tras haber sido escrito esto.</p> <p>El código de testing está disponible en <a href="http://ftp-master.debian.org/testing/update_out_code/";>ftp-master</a>.</p> <p><em>El crédito de la implementación de testing es para Anthony Towns.</em></p>
