La distribution de test de Debian

Pour les informations élémentaires destinées aux simples utilisateurs de la distribution de test, veuillez vous référer à la FAQ Debian.

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 ne sont pas gérées par l'équipe chargée de la sécurité. Pour de plus amples informations, référez-vous à la FAQ de l'équipe chargée de la sécurité.

Cette page traite principalement de l'importance que revêt la distribution de test pour les développeurs Debian.

Comment fonctionne la distribution de test ?

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.

Un paquet (ou une version particulière) sera déplacé dans la distribution de test lorsqu'il satisfera les critères suivants :

  1. Il doit avoir été dans la distribution instable pendant 10, 5 ou 2 jours, en fonction de l'urgence de la mise en ligne ;
  2. Il devra être compilé et à jour sur toutes les architectures sur lesquelles il a été compilé par le passé dans la distribution instable ;
  3. Il ne doit pas avoir de rapport de bogue entrant dans la catégorie critique pour la parution dans la prochaine distribution qui ne concerne pas déjà la version actuellement dans la distribution de test (regardez ci-dessous pour plus d'informations) ;
  4. Toutes ces dépendances doivent soit être satisfaites par les paquets d'ores et déjà présents dans la distribution de test, ou bien être satisfaites par un ensemble de paquets qui sont installés au même instant ;
  5. 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 plus d'informations) ;

Un paquet qui satisfait aux trois premiers critères ci-dessus est un Candidat Valide.

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 :

Foire aux questions

Que sont les bogues de type critique pour l'intégration dans la distribution (release-critical bugs), et comment sont-ils comptabilisés ?

Tous les bogues des niveaux supérieurs de gravité appartiennent par défaut à cette catégorie (release-critical) ; actuellement, ce sont les niveaux critical, grave et serious.

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 distribution de test, et par conséquent ne sera pas publié dans la distribution stable.

Le décompte des bogues de testing est effectué avec tous les bogues critiques pour la publication marqués pour s'appliquer à une combinaison de paquet/version disponible dans testing pour une architecture concernée par la publication.

Comment l'installation d'un paquet provenant de la distribution de test peut-elle casser d'autres paquets ?

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 acmefoo est installé dans la distribution de test, ainsi que ses paquets binaires acme-foo-bin, acme-bar-bin, libacme-foo1 et libacme-foo-dev, la version précédente est enlevée.

Néanmoins, il se peut que l'ancienne version ait fourni un paquet binaire avec un ancien nom-so d'une bibliothèque, comme libacme-foo0. Enlever l'ancien acmefoo enlèvera également libacme-foo0, ce qui cassera tout les paquets qui en dépendent.

É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 <<.

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.

Si vous êtes confronté à des problèmes complexes sur des groupes de paquets tels qu'évoqués ci-dessus, veuillez prendre contact avec debian-devel ou debian-release pour demander de l'aide.

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.

Cela peut se produire lorsque, directement ou indirectement l'installation du paquet empêche un autre paquet de fonctionner.

N'oubliez pas de prendre en compte les dépendances de votre paquet. Considérez que votre paquet dépend de libtool, ou libtdlX. Votre paquet n'ira pas dans la distribution de test tant que la bonne version de libtool n'est pas prête à y aller aussi.

De même, elle n'y entrera 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 que tous les paquets dépendants de libltdlY (où Y 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.

Dans ce genre de situation, la sortie textuelle [gzippée] 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 (consultez la référence du développeur pour plus de précisions).

Pourquoi est-il parfois difficile de mettre un paquet Architecture: all dans la distribution de test ?

Si un paquet valable pour toutes les architectures doit être installé, il doit pouvoir satisfaire l'ensemble de ses dépendances sur toutes 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.

Néanmoins, pour l'instant, la distribution de test ne vérifiera pas si le paquet peut être installé sur les architectures non-i386 (C'est un bidouillage grossier, je ne suis pas très fier de l'avoir fait, mais c'est comme ça --aj).

Mon paquet est bloqué car il est dépassé sur certaines architectures. Que dois-je faire ?

Vérifiez l'état de votre paquet dans la base de données de journaux de construction. Si le paquet ne se construit pas, il sera marqué comme failed ; analysez les comptes rendu de construction et corrigez chacun des problèmes dont l'origine se trouve votre paquet source.

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.

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 (Dep-Wait). Vous pouvez également regarder la liste de ce que l'on appelle en attente de construction pour vous en assurer.

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 la page des portages, ou sur la liste de diffusion du portage.

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 ftp.debian.org 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.

Y a-t-il des exceptions ? Je suis persuadé que acmefoo a été intégré dans la distribution de test malgré le fait qu'il ne réponde pas à tous les critères.

Le responsable de la publication peut transgresser les règles dans deux cas de figure :

Pouvez-vous fournir un exemple réel qui ne soit pas trivial ?

En voici un : lorsque le paquet source apache est installé dans la distribution de test, ainsi que ses paquets binaires apache, apache-common, apache-dev et apache-doc, l'ancienne version est enlevée.

Néanmoins, tous les modules d'Apache dépendent de apache-common (>=quelque chose), apache-common (<< quelque chose), 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.

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 apache-common et se rendent compte que tous les modules d'Apache sont cassés parce qu'ils possèdent Depends: apache-common (<< la version actuelle ; ensuite, ils essayent libapache-foo et trouvent qu'il ne s'installe pas parce qu'il possède Depends: apache-common (>= la nouvelle version).

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 apache-common 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 ça va fonctionner. Par la suite, ils testeront au hasard tous les paquets libapache-foo et constateront qu'ils fonctionnent.

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 update_output.txt sur les lignes recur:.

Par exemple : 

         recur: [foo bar] baz

dit grosso modo : j'ai trouvé que foo et bar amélioraient la situation, je vais maintenant essayer baz, même s'il casse quelque chose pour voir ce qui se passe. Les lignes du fichier update_output.txt qui commencent par accepted indiquent les éléments qui apparaissent comme étant bénéfiques, et les lignes skipped les éléments qui empirent la situation.

Le fichier update_output.txt est complètement illisible !

Ce n'est pas une question. ;-)

Prenons un exemple : 

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

Cela signifie que si cln est ajouté dans la distribution de test, ginac-cint et libginac-dev 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.

La ligne got 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 — voir ci-dessus). L'item i-45 signifie que si cln 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 cln 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à.

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.

Notez qu'il y plusieurs contrôles de tous les paquets lors de l'exécution d'un script de la distribution de test.

Jules Bean est à l'origine de la foire aux questions et de ses réponses.

Informations complémentaires

Les pages suivantes donnent des informations sur l'état de la distribution de test et sur la migration des paquets de unstable vers testing :

Vous serez peut être intéressé par la lecture d'un ancien courrier d' explication. 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.

Le code de testing est disponible sur la machine ftp-master.

Anthony Towns est l'auteur de l'implémentation de testing.