From: Charles Plessy Date: Tue, 28 Jun 2011 00:23:38 +0000 (+0900) Subject: Première relecture. X-Git-Url: https://source.charles.plessy.org/?a=commitdiff_plain;h=287ffb3c03fa7ee38086a9caa4cdc436ff1eaaa2;p=source%2F.git Première relecture. --- diff --git "a/Debian/debi\303\242neries/bioperl-et-tests.mdwn" "b/Debian/debi\303\242neries/bioperl-et-tests.mdwn" index 4dae411d..baf8d31b 100644 --- "a/Debian/debi\303\242neries/bioperl-et-tests.mdwn" +++ "b/Debian/debi\303\242neries/bioperl-et-tests.mdwn" @@ -4,53 +4,54 @@ [[!meta title="BioPerl et tests de régression"]] -Il y a deux semaines, j'ai mis à jour les paquets contentants les modules -BioPerl [[!debpkg bioperl]] et [[!debpkg bioperl-run]], ce qui a permi de -continuer le travail sur [[!debpkg gbrowse]], l'une des [[gbrowse navigateurs -de génome]] disponibles dans Debian. - -Comme beaucoup de modules Perl, BioPerl est accompagné d'une batterie de tests -de régression. Certains d'entre eux néecssitent un connection à des services -externes, et sont donc désactivés par défaut car l'accès à l'Internet n'est pas -garanti dans notre [ferme de construction](http://buildd.debian.org). Ils sont -néanmoins exécutables en passant l'option +Il y a deux semaines, j'ai mis à jour les paquets contentant les modules +BioPerl [[!debpkg bioperl]] et [[!debpkg bioperl-run]], ce qui a permis de +continuer le travail sur [[!debpkg gbrowse]], l'une des [[gbrowse|navigateurs +de génome]] disponibles dans Debian. Comme beaucoup de modules Perl, BioPerl +est accompagné d'une batterie de [tests de +régression](http://www.bioperl.org/wiki/HOWTO:Writing_BioPerl_Tests). Certains +d'entre eux nécessitent un connexion à des services externes, et sont donc +désactivés par défaut car l'accès à l'Internet n'est pas garanti dans notre +[ferme de construction](http://buildd.debian.org). Ils sont néanmoins +exécutables en passant l'option [DEB_MAINTAINER_MODE](http://lists.debian.org/debian-perl/2009/09/msg00044.html) lors de la construction du paquet. BioPerl passe avec succès tous les tests hors-ligne, et une partie des erreurs en ligne est déjà corrigée dans la [branche de -dévelopment](https://github.com/bioperl/bioperl-live). Au contraire, -BioPerl-Run échoue sur les tests Bowtie, DBA, EMBOSS, Genewise, Hmmer, PAML, -SABlastPlus, TCoffee et gmap-run. Dans certains cas comme EMBOSS, c'est parce -qu'un programme a été renommé dans Debian. Dans d'autres, en particulier -[[!debpkg wise DBA et Genewise]], il est beaucoup plus difficile de déterminer -de quel côté est le problème. +dévelopment](https://github.com/bioperl/bioperl-live/tree/HEAD/t). Au +contraire, BioPerl-Run échoue sur les tests Bowtie, DBA, EMBOSS, Genewise, +Hmmer, PAML, SABlastPlus, TCoffee et gmap-run. Dans certains cas comme EMBOSS, +c'est parce qu'un programme a été renommé dans Debian. Dans d'autres, en +particulier [[!debpkg wise desc="DBA et Genewise"]], il est beaucoup plus +difficile de déterminer de quel côté est le problème. Les tests de régression sont essentiels pour déterminer si un paquet fonctionne -ou non sur les plate-formes autres que celles utilisées par l'empaqueteur -(amd64 dans mon cas). Même les plus simples peuvent être utiles. Dans le -cas de [[!debpkg t-coffee]], qui fournit un test très simple que j'ai activé -récemment, cela a montré que les paquets distribués actuellement pour armel -[[!debbug 631249 desc="ne fonctionnent pas du tout"]. +ou non sur les plates-formes autres que celles utilisées par l'empaqueteur +(amd64 dans mon cas). Même les plus simples peuvent être utiles. Dans le cas +de [[!debpkg t-coffee desc="T-Coffee"]], qui fournit un test très simple que +j'ai activé récemment, cela a montré que les paquets distribués actuellement +pour armel [[!debbugs 631249 desc="ne fonctionnent pas du tout"]. Exécuter les tests de régression durant la construction du paquet comporte des avantages, comme d'avoir le résultat automatiquement publié pour toutes les -architectures via un serveur de journeaux comme buildd.debian.org. Mais cela -pose aussi d'autres problèmes. Permièrement, cela peut demander d'élargir la -liste des dépendances de construction. Ainsi, bioperl-run doit dépendre de -tous les programmes pour lesquels il fournit une interface si on veut le tester -efficacement. Et dans ce cas particulier, tant que T-Coffee est défectueux sur -armel, BioPerl-Run ne peut pas être reconstruit sur cette plate-forme. +architectures via les [journaux de +construction](https://buildd.debian.org/status/logs.php?pkg=t-coffee&ver=8.99-1). +Mais cela pose aussi d'autres problèmes. Premièrement, cela peut demander +d'élargir la liste des dépendances de construction. Ainsi, bioperl-run doit +dépendre de tous les programmes pour lesquels il fournit une interface si on +veut le tester efficacement. Et dans ce cas particulier, tant que t-coffee est +défectueux sur armel, bioperl-run ne peut pas être reconstruit sur cette +plate-forme. Deuxièmement, cela ne fournit pas un moyen simple à l'utilisateur de tester un -paquet installé sur son système. La proposition DEP 8 va à mi-chemin dans ce -sens, car elle a pour but de tester, au moment de la construction, les -programmes non pas tels qu'ils sont construits, mais tels qu'ils sont -empaquetés. C'est un pas dans une bonne direction. Peut-être sera-t-il -possible de construire sur ce projet de manière à ce qu'un jour on puisse aussi -tester les paquets binaires. Cela permettrait de faire les tests non pas au -moment de la construction, mais juste après, et ainsi peut-être d'introduire -plus de flexibilité dans les dépendances, pour éviter qu'un seul programme -manquant n'invalide complètement un paquet qui peut l'utiliser de manière -optionelle. - +paquet installé sur son système. La proposition +[DEP 8](http://dep.debian.net/deps/dep8/) va à mi-chemin dans ce sens, car elle +a pour but de tester, au moment de la construction, les programmes non pas tels +qu'ils sont construits, mais tels qu'ils sont empaquetés. C'est un pas dans +une bonne direction. Peut-être sera-t-il possible de construire sur ce projet +de manière à ce qu'un jour on puisse aussi tester les paquets binaires. Cela +permettrait de faire les tests non pas au moment de la construction, mais juste +après, et ainsi peut-être d'introduire plus de flexibilité dans les +dépendances, pour éviter qu'un seul programme manquant n'invalide complètement +un paquet qui peut l'utiliser de manière optionnelle.