Avec le fichier - [DDR] webwml://devel/testing.wml
Yop,
avec le fichier c'est mieux :-)
a+
--
Pierre Machard
<pmachard@tuxfamily.org> TuxFamily.org
<pmachard@techmag.net> techmag.net
+33(0)668 178 365 http://migus.tuxfamily.org/gpg.txt
GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87
#use wml::debian::template title="La distribution Debian « testing »" BARETITLE=true
#include "$(ENGLISHDIR)/releases/info"
#use wml::debian::translation-check translation="1.9" maintainer="Pierre Machard"
<p>Pour les informations essentielles à destination des utilisateurs au sujet
de la distribution <i>testing</i> veuillez-vous référer à
<a href="$(DOC)/FAQ/ch-ftparchives#s-testing">la FAQ Debian</a>.</p>
<p>Une chose importante à noté, à la fois pour les utilisateurs usuels
et les développeurs de <i>testing</i>, est que les mises à jour de sécurité
pour <i>testing</i> <strong>ne sont pas gérées par l'équipe chargée de la
sécurité</strong>. Pour de plus amples informations, référez-vous à la
<a href="../security/faq#testing">FAQ de l'équipe chargée de la
sécurité</a>.</p>
<p>Cette page traite principalement de l'importance que revêt
« testing » pour les développeurs Debian.</p>
<h2>Comment fonctionne « testing » ?</h2>
<p>La distribution « testing » est une distribution générée
automatiquement. Elle est générée à partir de la distribution
« unstable » par un ensemble de scripts qui tentent d'intégrer
les paquets qui selon toute vraisemblance ne contiennent pas de bogues
importants. Ils s'assurent que les dépendances des autres paquets de
<i>testing</i> soient toujours préservées.</p>
<p>Un paquet (pour une version particulière) sera déplacé dans <i>testing</i>
lorsqu'il satisfera les critères suivants :</p>
<ol>
<li>Il doit avoir été dans <i>unstable</i> pendant 10, 5 ou 2 jours,
en fonction de l'urgence de la mise en ligne ;</li>
<li>Il devra être compilé et à jour sur toutes les architectures sur
lesquelles il a été compilé par le passé dans <i>unstable</i> ;</li>
<li>Il doit avoir moins de rapport de bogue critique pour la publication que
la même version actuellement dans « testing » (<a href="#faq">
regardez ci-dessous</a> pour plus d'informations) ;</li>
<li>Toutes ces dépendances doivent <em>soit</em> être satisfaites
par les paquets d'ores et déjà présents dans <i>testing</i>, <em>ou bien</em>
être satisfaites par un ensemble de paquets qui seront installés au même
instant ;</li>
<li>L'opération d'installation des paquets dans « testing »
ne doit pas casser un seul paquet actuellement dans « testing ».
(<a href="#faq">regardez ci-dessous</a> pour plus d'informations) ;</li>
</ol>
<p>Un paquet qui satisfait aux trois premiers critères ci-dessus est un
<q>Candidat Valide</q>.</p>
<p>Le script de mise à jour montre lorsque chaque paquet est déplacé de
« unstable » dans « testing ». La sortie est
dupliquée :</p>
<ul>
<li>La <a href="http://ftp-master.debian.org/testing/update_excuses.html";>\
mise à jour des excuses</a>
[<a href="http://ftp-master.debian.org/testing/update_excuses.html.gz";>\
gzipped</a>] :
liste l'ensemble des versions des paquets candidats et l'état
de base de leur propagation dans « testing » c'est
beaucoup plus digeste que :
</li>
<li>La <a href="http://ftp-master.debian.org/testing/update_output.txt";>\
sortie de la mise à jour</a>
[<a href="http://ftp-master.debian.org/testing/update_output.txt.gz";>\
gzipped</a>] :
La sortie complète, plutôt indigeste des scripts « testing »
compte tenu de la récurssivité des candidats.
</li>
</ul>
<h2><a name="faq">Foire Aux Questions</a></h2>
<h3><q>Que sont les bogues critique pour la publication (<i>release-critical
bugs</i>), et comment sont-ils comptabilisés ?</q></h3>
<p>Tous les bogues dont le degré de sévérité est important sont, par défaut,
considérés comme
<em><a href="http://bugs.debian.org/release-critical/";>release-critical</a></em> ;
actuellement, il y a des bogues <strong>critical</strong>,
<strong>grave</strong> et <strong>serious</strong>.</p>
<p>De tels bogues sont présumés avoir une incidence sur les possibilités
que le paquet soit publié dans la publication stable de Debian : En
règle générale, si un paquet a un rapport de bogues critique pour la
publication, il n'ira pas dans « testing », et sera par conséquent
ne sera pas publié dans « stable ».</p>
<p>le décompte des bogues d'un paquet de « testing » est considéré
comme étant important dès lors que le dernier décompte dans
« testing » est identique à celui dans « unstable ».
Les bogues marqués <strong><current_release_name></strong> ou
<strong><current_testing_name></strong> ne seront pas considérés. Les
bogues avec le marquage <strong>sid</strong> seront cependant pris en
compte.</p>
<h3><q>Comment l'installation d'un paquet provenant de « testing »
peut éventuellement casser d'autres paquets ?</q></h3>
<p>La structure des archives de la distribution est telle qu'elles ne
peuvent uniquement contenir une version d'un paquet ; un paquet est
défini par son nom. Aussi lorsque le paquet source <tt>acmefoo</tt> est
installé dans « testing », ainsi que ses paquets binaires
<tt>acme-foo-bin</tt>, <tt>acme-bar-bin</tt>, <tt>libacme-foo1</tt> et
<tt>libacme-foo-dev</tt>, la version précédente est enlevée.</p>
<p>Néanmoins, l'ancienne version doit avoir fourni un paquet binaire et
également une vieille bibliothèque qui porte le même nom, comme
<tt>libacme-foo0</tt>. Enlever l'ancien <tt>acmefoo</tt> enlèvera également
<tt>libacme-foo0</tt>, ce qui cassera tout les paquets qui en dépendent.</p>
<p>Évidemment, cela affecte principalement les paquets qui fournissent
des ensembles de paquets binaires dans différentes versions (et dans le
même temps les bibliothèques les plus importantes). Néanmoins,
cela aura aussi des conséquences pour les paquets dont les versions
de dépendances ont été déclarées soit ==, <= ou <<.</p>
<h3><q>Je ne comprends toujours pas ! Les scripts « testing »
disent que ce paquet est un candidat valide, mais il n'est toujours pas
dans « testing ».</q></h3>
<p>Cela peut se produire lorsque quelque part, directement ou indirectement
l'installation du paquet empêchera un autre paquet de fonctionner.</p>
<p>N'oubliez pas de prendre en compte les dépendances de votre paquet.
Considérez que votre paquet dépends de libtool, ou libtdl<var>X</var>.
Votre paquet n'ira pas « testing » tant que la bonne version
de libtool ne soit prête à y aller.</p>
<p>En un mot, cela n'arrivera pas tant que l'installation de libtool
ne provoquera pas de casse sur les paquets qui se trouvent déjà dans
« testing ». En d'autres termes, jusqu'à ce que tous les paquets
qui dépendent de libltdl<var>Y</var> (où <var>Y</var> est une version
précédente) n'aient été recompilés, et que tous les bogues critiques pour
la publication n'aient été corrigés, etc, aucun de ces paquets n'entrera dans
« testing ».</p>
<p>Dans ce genre de situation, la<a
href="http://ftp-master.debian.org/testing/update_output.txt";>\
sortie textuelle</a>
[<a href="http://ftp-master.debian.org/testing/update_output.txt.gz";>gzippée</a>]
est utile : elle fournit bon nombre d'informations (qu'il faut néanmoins
décoder) sur les paquets cassés lorsqu'un candidat valide est ajouté dans
« testing ».</p>
<h3><q>Pourquoi est-il parfois difficile d'obtenir un paquet pour toutes
les architectures (<i><kbd>Architecture: all</kbd></i>) dans
« testing » ?</q></h3>
<p>Si le paquet pour toute les architectures est sur le point d'être installé,
il doit pouvoir satisfaire l'ensemble de ses dépendances sur
<strong>toutes</strong> les architectures. S'il dépend d'un paquet en
particulier qui ne compiler que sur un nombre limité d'architecture de Debian,
il ne pourra pas être inclus.</p>
<p>Néanmoins, pour l'instant, « testing » ignorera
l'installation des paquets pour toutes les architectures sur les
architecture non-i386. (« C'est une décision autoritaire, je ne suis
pas très fier de l'avoir prise, mais c'est comme ça » --aj)</p>
<h3><q>Y-a-il des exceptions ? Je suis persuadé que <tt>acmefoo</tt>
a été inséré dans « testing » malgré le fait qu'il ne réponde
pas à tous les critères.</q></h3>
<p>Les responsables de la publication peuvent transgresser les règles dans
deux cas de figure :</p>
<ul>
<li>Ils peuvent décider que la rupture engendrée par l'installation
d'une nouvelle bibliothèque sera un bienfait, et on prendra le parti
d'avoir des problèmes de dépendances.</li>
<li>Ils peuvent également enlever de façon manuelle des paquets de
« testing » qui pourraient être cassés, de sorte qu'on puisse
installer de nouveaux éléments.</li>
</ul>
<h3><q>Pouvez-vous fournir un vrai exemple qui ne soit pas
trivial ?</q></h3>
<p>En voici un : lorsqu'un paquet source <tt>apache</tt> est sur
le point d'être installé, ainsi que ses paquets binaires <tt>apache</tt>,
<tt>apache-common</tt>, <tt>apache-dev</tt> et <tt>apache-doc</tt>,
l'ancienne version sera enlevée.</p>
<p>Néanmoins, tous les modules d'Apache dépendent de <code>apache-common
(>=<var>quelque chose</var>), apache-common (<< <var>quelque
chose</var>)</code>, aussi ce changement cassera toutes ces dépendances.
Par conséquent, tous les modules d'Apache devront être recompilés pour
la dernière version d'Apache pour que « testing » soit mis à
jour.</p>
<p>Continuons notre analyse plus en avant : une fois que tous les
modules auront été mis à jour dans <i>unstable</i> afin de fonctionner
avec un nouvel Apache, les scripts de « testing » testeront
<tt>apache-common</tt> et vont se rendre compte que tous les modules
d'Apache risquent d'être cassés par ce qu'ils possèdent <code>Depends:
apache-common (<< <var>la version actuelle</var></code>, et alors
ils essayeront <tt>libapache-<var>foo</var></tt> et trouveront qu'il
ne s'installe pas parce qu'il possède <code>Depends: apache-common (>=
<var>la nouvelle version</var>)</code>.</p>
<p>Néanmoins, par la suite il appliquera une logique différente (quelque fois
provoquée par une intervention manuelle) : il ignorera le fait
que <tt>apache-common</tt> provoque de la casse, et continuera avec
les choses qui fonctionnent ; si cela ne fonctionne toujours pas trop
mal après toutes ces tentatives, on peut penser que cela <strong>ça va
fonctionner</strong>. Par le suite, il testera tous les divers paquets
<tt>libapache-<var>foo</var></tt> et regardera si ça fonctionne.</p>
<p>Après toute les tentatives d'essai, il contrôle le nombre de paquets
qui ont été cassés, découvre si c'est plutôt un bien ou un mal par rapport
à la situation d'origine et soit il accepte tout, soit il rejette.
Vous verrez cela dans le fichier <tt>update_output.txt</tt> sur les lignes
« <code>recur:</code> ».</p>
<p>Par exemple :</p>
<pre>
recur: [<var>foo</var> <var>bar</var>] <var>baz</var>
</pre>
<p>qui dit grosso modo qu'il a découvert que <var>foo</var> et
<var>bar</var> améliorait la situation, je vais maintenant essayer
<var>baz</var>, même si il casse quelque chose pour voir ce qui se passe</q>.
Les lignes du fichier <tt>update_output.txt</tt> qui commencent par
« <code>accepted</code> » indiquent les élément qui apparaissent
comme étant bénéfiques, et les lignes « <code>skipped</code> »
empire la situation.</p>
<h3><q>Le fichier <tt>update_output.txt</tt> est complètement
illisible !</q></h3>
<p>Ce n'est pas une question. ;-)</p>
<p>Prenons un exemple :</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>Cela signifie que si <tt>cln</tt> est ajouté dans « testing »,
<tt>ginac-cint</tt> et <tt>libginac-dev</tt> ne pourront plus être installés
dans « testing » sur i386. Notez que les architectures
sont contrôlées dans l'ordre alphabétique et seul les problèmes
survenants sur la première architecture sont repportés -- c'est pourquoi on
voit souvent l'architecture alpha.</p>
<p>La ligne « got » inclu le numéro du problème dans
« testing » sur différentes architectures (jusqu'à ce que la
première architecture où l'on trouve un problème -- regardez au dessus).
les « i-45 » signifie que si <tt>cln</tt> est ajouté dans
« testing », il y aura 45 paquets qui ne pourront plus
être installés sur i386. Quelques une des entrées au-dessus et en-dessous
de <tt>cln</tt> montrent qu'il y avait 43 paquets qui ne pouvaient pas
être installés dans «nbsp;testing » i386 à ce moment la.</p>
<p>La ligne « skipped: cln (0) (150+4) » signifie qu'il
y a toujours 150 paquets à vérifier après ce paquet pour que le contrôle
de tous les paquets soit achevé, et que 4 paquets ont d'ores et déjà
été identifiés et ne seront pas mis à jour car ils casseraient des
dépendances. Le « (0) » n'est pas significatif, vous pouvez
l'ignorer.</p>
<p>Notez qu'il y plusieurs contrôles de tous les paquets lors
de l'exécution d'un script « testing ».</p>
<p><i>Jules Bean est à l'origine de la foire aux questions et
de ses réponses.</i></p>
# Created: Sat Dec 8 12:44:29 GMT 2001
<h2>Informations complémentaires</h2>
<p>Les scripts détectent également les bogues que l'on peut qualifier
de horriblement-severe-ne-devrait-pas-se-trouver-ici-pour-commencer.
Ceci représente les paquets « pour lesquels il ne se préoccupe même pas
de l'inclusion », qui disparaitreront heureusement lors du processus
de gel, et les soirées de deboguage massif par exemple.
<br>
Il y a des listes de tels bogues pour les trois distributions :
<ul>
<li><a href="http://ftp-master.debian.org/testing/testing_probs.html";>problème dans <i>testing</i></a> ;</li>
<li><a href="http://ftp-master.debian.org/testing/unstable_probs.html";>problème dans <i>unstable</i></a> ;</li>
<li><a href="http://ftp-master.debian.org/testing/stable_probs.html";>problème dans <i>stable</i></a>.</li>
</ul>
<p>En plus de cela, voici quelques statistiques sur les paquets binaires
qui ne sont pas à jour pour
<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> and
<a href="http://ftp-master.debian.org/testing/unstable_outdate.txt";>unstable</a>.</p>
<p>Vous serez peut être intéressé par la lecture d'un ancien
<a href="http://lists.debian.org/debian-devel-0008/msg00906.html";>email d'
explication</a>. Ce courriel montre que les principaux problèmes sont
dûs au fait qu'on ne prend pas en considération l'ensemble des paquets,
parce que c'est James Troup qui en est à l'orignie et que cette implémentation
a été réalisé après que le script eu été écrit.</p>
<p>Le code de testing est disponible via un CVS anonyme à partir de
<a href="http://cvs.debian.org/testing/?cvsroot=dak";>cvs.debian.org</a>.
Configurez votre <code>CVSROOT</code> avec
<kbd>:pserver:anonymous@cvs.debian.org:/cvs/dak</kbd>, et le module
<kbd>testing</kbd>.</p>
<p><i>Anthony Towns est l'auteur de l'implémentation de testing.</i></p>
Reply to: