-- .~. Nicolas Bertolissio /V\ [EMAIL PROTECTED] // \\ /( )\ ^`~'^ Debian GNU-Linux
#use wml::debian::template title="La distribution de test de Debian" BARETITLE=true #include "$(ENGLISHDIR)/releases/info" #use wml::debian::translation-check translation="1.25" maintainer="Pierre Machard"
<p>
Pour les informations élémentaires destinées aux simples utilisateurs de la
distribution de test, veuillez vous référer à <a
href="$(DOC)/FAQ/ch-ftparchives#s-testing">la FAQ Debian</a>.
</p>
<p>
Les simples utilisateurs et les développeurs de la distribution de test doivent
savoir que les mises à jour de sécurité pour la distribution de test <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 la distribution de
test pour les développeurs Debian.
</p>
<h2>Comment fonctionne la distribution de test ?</h2>
<p>
La distribution de test est une distribution générée automatiquement. Elle est
générée à partir de la distribution instable par un ensemble de scripts qui
tentent d'intégrer les paquets qui selon toute vraisemblance ne contiennent pas
de bogues critiques pour la publication. Ils s'assurent que les dépendances des
autres paquets de la distribution de test soient toujours préservées.
</p>
<p>
Un paquet (ou une version particulière) sera déplacé dans la distribution de
test lorsqu'il satisfera les critères suivants :
</p>
<ol>
<li>Il doit avoir été dans la distribution instable 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 la distribution
instable ;</li>
<li>Il doit avoir moins (ou le même nombre) de rapport de bogue entrant dans
la catégorie critique pour la parution dans la prochaine distribution <!--
oui, c est long mais ça me parait correct ; voir la discussion sur l10n !
-->que la version actuellement dans la <q>distribution de test</q>
(regardez ci-dessous pour <a href="#faq">plus
d'informations</a>) ;</li>
<li>Toutes ces dépendances doivent <em>soit</em> être satisfaites par les
paquets d'ores et déjà présents dans la distribution de test, <em>ou
bien</em> être satisfaites par un ensemble de paquets qui sont installés au
même instant ;</li>
<li>L'opération d'installation des paquets dans la distribution de test ne
doit pas casser un seul paquet actuellement dans cette distribution
(regardez ci-dessous pour <a href="#faq">plus
d'informations</a>) ;</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 indique quand un paquet peut-être déplacé de la
distribution instable vers la distribution de test. La sortie a deux
formes :
</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";>\
gzippée</a>] : liste l'ensemble des versions des paquets candidats et
l'état de base de leur propagation dans la distribution de test 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";>\
gzippée</a>] : La sortie complète, plutôt indigeste des scripts de la
distribution de test compte tenu de la récursivité des candidats.
</li>
</ul>
<h2><a name="faq">Foire aux questions</a></h2>
<h3><q>Que sont les bogues de type critique pour l'intégration dans la
distribution <!-- nouvelle formulation ! -->(<i>release-critical bugs</i>), et
comment sont-ils comptabilisés ?</q></h3>
<p>
Tous les bogues des niveaux supérieurs de gravité appartiennent par défaut à
cette catégorie (<em><a href="http://bugs.debian.org/release-critical/";>\
release-critical</a></em>) ; actuellement, ce sont les niveaux
<strong>critical</strong>, <strong>grave</strong> et <strong>serious</strong>.
</p>
<p>
De tels bogues sont présumés avoir une incidence sur l'intégration du paquet
dans la distribution stable de Debian : En règle générale, si un paquet a
un rapport de bogue appartenant à cette catégorie, il n'ira pas dans la
distrtibution de test, et par conséquent ne sera pas publié dans la
distribution stable.
</p>
<p>
Le décompte des bogues d'un paquet de la distribution de test est le décompte
fait quand cette distribution est identique à la distribution instable. Les
bogues marqués <strong><current_release_name></strong> ou <strong>\
<current_testing_name></strong> ne sont pas pris en compte. Les bogues avec le
marquage <strong>sid</strong> seront cependant pris en compte.
</p>
<h3><q>Comment l'installation d'un paquet provenant de la distribution de test
peut-elle casser d'autres paquets ?</q></h3>
<p>
La structure des archives de la distribution est telle qu'une distribution ne
peut contenir qu'une seule version d'un paquet ; un paquet est défini par
son nom. Aussi lorsque le paquet source <tt>acmefoo</tt> est installé dans la
distribution de test, 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, il se peut que l'ancienne version ait fourni un paquet binaire avec
un ancien nom-so d'une bibliothèque<!-- voir la charte et le chapitre sur les
bibliothèques -->, 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 principalement les
bibliothèques). Néanmoins, cela concerne aussi les paquets pour lesquels des
dépendances pour des versions précises ont été déclarées avec ==, <= ou
<<.
</p>
<p>
Lorsque l'ensemble des paquets binaires issu d'un paquet source est modifié,
tous les paquets qui dépendent des anciens paquets binaires doivent être mis à
jour pour dépendre maintenant des nouveaux paquets binaires. Étant donné que
l'installation d'un tel paquet source dans la distribution de test cassera
tous les paquets de cette distribution qui en dépendent, il est nécessaire de
prendre quelques dispositions : tous les paquets en dépendant doivent être
mis à jour et être prêts à être installés pour éviter la casse, une fois que
tout est prêt, une intervention manuelle du responsable de la publication ou
d'un assistant est nécessaire.
</p>
<p>
Si vous êtes confronté à des problèmes complexes sur des groupes de paquets
tels qu'évoqués ci-dessus, veuillez prendre contact avec <q>debian-devel</q> ou
<q>debian-release</q> pour demander de l'aide.
</p>
<h3><q>Je ne comprends toujours pas ! Les scripts de la distribution de
test disent que ce paquet est un candidat valide, mais il n'est toujours pas
dans cette distribution.</q></h3>
<p>
Cela peut se produire lorsque, directement ou indirectement l'installation du
paquet empêche 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 la distribution de test tant que la bonne version de libtool n'est pas
prête à y aller aussi.
</p>
<p>
Et, elle n'ira pas tant que l'installation de libtool provoquera de la casse
sur les paquets qui se trouvent déjà dans la distribution de test. En d'autres
termes, tant ce que tous les paquets qui dépendent de libltdl<var>Y</var> (où
<var>Y</var> est une version précédente) n'auront pas été recompilés, et que
tous les bogues de type critique pour l'intégration dans la distribution
n'auront pas été corrigés, etc., aucun de ces paquets n'entrera dans la
distribution de test.
</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 la
distribution de test.
</p>
<h3><q>Pourquoi est-il parfois difficile de mettre un paquet
<i><kbd>Architecture: all</kbd></i> dans la distribution de
test ?</q></h3>
<p>
Si un paquet valable pour toutes les architectures doit ê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 qui ne compile que sur un nombre
limité d'architectures de Debian, il ne pourra pas être inclus.
</p>
<p>
Néanmoins, pour l'instant, la distribution de test ne vérifiera pas si le
paquet peut être installé sur les architectures non-i386 (<q>C'est un <i>gross
hack</i>, je ne suis pas très fier de l'avoir fait, mais c'est comme ça</q>
--aj).
</p>
<h3><q>Mon paquet est bloqué car il est dépassé sur certaines architectures.
Que dois-je faire ?</q></h3>
<p>
Vérifiez l'état de votre paquet dans la <a
href="http://buildd.debian.org/build.php";>base de données de journaux de
construction</a>. Si le paquet ne se construit pas, il sera marqué comme
<em>failed</em> ; analysez les comptes rendu de construction et corrigez
chacun des problèmes dont l'origine se trouve votre paquet source.
</p>
<p>
Si vous constatez que certaines architectures ont construit la nouvelle version
de votre paquet, mais que cela n'apparaît pas dans la sortie des scripts de la
distribution de test, alors vous devrez vous armer de patience et attendre que
le responsable du buildd correspondant mette en ligne le fichier dans l'archive
Debian.
</p>
<p>
Si vous constatez que certaines architectures n'ont pas du tout construit la
nouvelle version de votre paquet, malgré le fait que vous ayez mis en ligne une
rustine pour réparer l'échec précédent, la raison est selon toute vraisemblance
que votre paquet est marqué comme attendant des dépendances (<i>Dep-Wait</i>).
Vous pouvez également regarder la liste de ce que l'on appelle <a
href="http://buildd.debian.org/stats/";>en attente de construction</a> pour vous
en assurer.
</p>
<p>
Ces problèmes sont en définitive généralement corrigés, mais si vous attendez
déjà depuis un bon moment (disons deux semaines et plus), notifiez le
responsable des buildd concerné si une telle adresse est fournie sur <a
href="$(HOME)/ports/">la page des portages</a>, ou sur la liste de diffusion du
portage.
</p>
<p>
Si vous avez explicitement supprimé l'architecture de la liste Architecture
danns le fichier control et que le paquet avait déjà été construit pour cette
architecture, vous devez demander la suppression de l'archive des anciens
paquets binaires de cette architecture avant que votre paquet ne puisse
effectuer sa transition vers la distribution de test. Vous devez remplir un
rapport de bogue contre <q>ftp.debian.org</q> demandant la suppression de
l'archive instable des paquets de l'architecture abandonnée. En général, la
liste de diffusion du portage correspondant doit en être informée par
courtoisie.
</p>
<h3><q>Y a-t-il des exceptions ? Je suis persuadé que <tt>acmefoo</tt> a
été intégré dans la distribution de test malgré le fait qu'il ne réponde pas à
tous les critères.</q></h3>
<p>
Le responsable de la publication peut transgresser les règles dans deux cas de
figure :
</p>
<ul>
<li>Il peut décider que la rupture engendrée par l'installation d'une
nouvelle bibliothèque sera un bienfait, et il l'installera avec sa
flottille de dépendances ;</li>
<li>Il peut également enlever de façon manuelle des paquets de la
distribution de test, qui autrement seraient cassés, pour pouvoir installer
de nouveaux éléments.</li>
</ul>
<h3><q>Pouvez-vous fournir un exemple réel qui ne soit pas
trivial ?</q></h3>
<p>
En voici un : lorsque le paquet source <tt>apache</tt> est installé dans
la distribution de test, ainsi que ses paquets binaires <tt>apache</tt>,
<tt>apache-common</tt>, <tt>apache-dev</tt> et <tt>apache-doc</tt>, l'ancienne
version est 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 avec la dernière
version d'Apache pour que la distribution de test soit mise à jour.
</p>
<p>
Continuons notre analyse plus avant : une fois que tous les modules ont
été mis à jour dans la distribution instable afin de fonctionner avec un nouvel
Apache, les scripts de la distribution de test testent <tt>apache-common</tt>
et se rendent compte que tous les modules d'Apache sont cassés parce qu'ils
possèdent <code>Depends: apache-common (<< <var>la version
actuelle</var></code> ; ensuite, ils essayent
<tt>libapache-<var>foo</var></tt> et trouvent 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, les scripts appliqueront une logique différente
(quelque fois provoquée par une intervention manuelle) : ils ignoreront le
fait que <tt>apache-common</tt> provoque de la casse, et continueront avec les
choses qui fonctionnent ; si cela ne fonctionne toujours pas, après toutes
ces tentatives, tant pis ! mais peut-être que <strong>ça va
fonctionner</strong>. Par le suite, ils testeront au hasard tous les paquets
<tt>libapache-<var>foo</var></tt> et constateront qu'ils fonctionnent.
</p>
<p>
Après que tout a été essayé, ils contrôlent le nombre de paquets qui ont été
cassés, cherchent si c'est plutôt un bien ou un mal par rapport à la situation
d'origine et soit ils acceptent tout, soit ils rejettent tout. Vous verrez
cela dans le fichier <tt>update_output.txt</tt> sur les lignes
<q><code>recur:</code></q>.
</p>
<p>
Par exemple :
</p>
<pre>
recur: [<var>foo</var> <var>bar</var>] <var>baz</var>
</pre>
<p>
dit grosso modo : <q>j'ai trouvé que <var>foo</var> et <var>bar</var>
amélioraient la situation, je vais maintenant essayer <var>baz</var>, même s'il
casse quelque chose pour voir ce qui se passe</q>. Les lignes du fichier
<tt>update_output.txt</tt> qui commencent par <q><code>accepted</code></q>
indiquent les éléments qui apparaissent comme étant bénéfiques, et les lignes
<q><code>skipped</code></q> les éléments qui empirent 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 la distribution de test,
<tt>ginac-cint</tt> et <tt>libginac-dev</tt> ne pourront plus être y installés
sur l'architecture i386. Notez que les architectures sont contrôlées dans
l'ordre alphabétique et seuls les problèmes survenants sur la première
architecture en défaut sont rapportés — c'est pourquoi on voit
souvent l'architecture alpha.
</p>
<p>
La ligne <q>got</q> inclut le nombre de problèmes dans la distribution de test
sur différentes architectures (jusqu'à la première architecture où l'on trouve
un problème &mdahs; voir ci-dessus). L'item <q>i-45</q> signifie que si
<tt>cln</tt> est ajouté dans la distribution de test, il y aura 45 paquets
qui ne pourront plus être installés sur l'architecture i386. Quelques 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 la distribution de test pour
l'architecture i386 à ce moment-là.
</p>
<p>
La ligne <q>skipped: cln (0) (150+4)</q> 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 <q>(0)</q>
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 de la distribution de test.
</p>
<p>
<em>Jules Bean est à l'origine de la foire aux questions et de ses réponses.</em>
</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
<em>horriblement-grave-ne-devrait-pas-se-trouver-ici-pour-commencer</em>. Ce
sont tous des insultes du type <q>ne-vous-embêtez-pas-à-inclure ce paquet</q>,
qui disparaîtront heureusement lors du processus de gel, et les soirées de
débogage massif par exemple.
<br />
Il y a des listes de tels bogues pour les trois distributions :
</p>
<ul>
<li><a href="http://ftp-master.debian.org/testing/testing_probs.html";>\
problèmes dans la distribution de test</a> ;</li>
<li><a href="http://ftp-master.debian.org/testing/unstable_probs.html";>
problèmes dans la distribution instable</a> ;</li>
<li><a href="http://ftp-master.debian.org/testing/stable_probs.html";>\
problèmes dans la distribution stable</a>.</li>
</ul>
<p>
En plus de cela, voici quelques statistiques sur les paquets binaires qui ne
sont pas à jour pour les distibutions
<a href="http://ftp-master.debian.org/testing/testing_outdate.txt";>de test</a>,
<a href="http://ftp-master.debian.org/testing/stable_outdate.txt";>stable</a> et
<a href="http://ftp-master.debian.org/testing/unstable_outdate.txt";>instable</a>.
</p>
<p>
Björn Stenberg a écrit une <a href="http://bjorn.haxx.se/debian/";>\
interface</a> pour vous aider à découvrir pourquoi les paquets sont retenus en
dehors de la distribution de test.
</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";>courrier d'
explication</a>. Son seul défaut est de ne pas prendre en considération
l'organisation en pool des paquets ; mais il a été écrit avant que cette
organisation ne soit mise en place par James Troup.
</p>
<p>
Le code de testing est disponible sur la machine <a
href="http://ftp-master.debian.org/testing/update_out_code/";>ftp-master</a>.
</p>
<p>
<em>Anthony Towns est l'auteur de l'implémentation de testing.</em>
</p>
signature.asc
Description: Digital signature
