[RFR] wml://devel/testing
Buenos días
Por favor ayudadme con esta traducción porque veo algunas cosas que no
sé si estoy traduciendo bien:
1.- (línea 33 en inglés, 36 en español)
<li>It must not have release-critical bugs which do not also apply to
the version currently in <q>testing</q> (see below for
<a href="#faq">more information</a>);</li>
<li>Debe no tener los fallos críticos que 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>
2.- En la línea 105 aparece un "soname" que no sé si se debe dejar así
o traducirlo, y e (estaba así en la anterior versión):
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.
Original en inglés:
However, the old version may have provided a binary package with an
old soname of a library, such as libacme-foo0. Removing the old
acmefoo will remove libacme-foo0, which will break any packages which
depend on it.
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>Debe no tener los fallos críticos que 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>
Reply to: