From: Charles Plessy Date: Tue, 28 Jun 2011 22:37:37 +0000 (+0900) Subject: Une autre relecture. X-Git-Url: https://source.charles.plessy.org/?a=commitdiff_plain;h=c7346ca128b98d08cd15e2a94002426e0f494f72;p=source.git Une autre relecture. --- diff --git "a/Debian/debi\303\242neries/bioperl-et-tests.mdwn" "b/Debian/debi\303\242neries/bioperl-et-tests.mdwn" index d463d0c6..93929374 100644 --- "a/Debian/debi\303\242neries/bioperl-et-tests.mdwn" +++ "b/Debian/debi\303\242neries/bioperl-et-tests.mdwn" @@ -18,39 +18,39 @@ exécutables en utilisant la variable d'environnement quand le paquet est construit localement. BioPerl passe avec succès tous les tests hors-ligne, et une partie des erreurs -des tests en ligne est déjà corrigée dans la [branche de +des tests en ligne est déjà corrigée dans sa [branche de 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, +Hmmer, PAML, SABlastPlus, T-Coffee et gmap-run. Dans certains cas comme EMBOSS, c'est parce qu'un programme a été renommé dans Debian. Dans d'autres cas, 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 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 rudimentaire 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 [portages](http://www.debian.org/ports/) autres que ceux +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 rudimentaire 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"]]. 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 les [journaux de +avantages, comme d'avoir le résultat automatiquement publié pour chaque portage +via les [journaux de construction](https://buildd.debian.org/status/logs.php?pkg=t-coffee&ver=8.99-1). -Mais cela pose aussi des 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. +Mais cela pose aussi des problèmes. Premièrement, cela demande de dépendre de +tous les programmes pour lesquels un paquet fournit une interface si on veut le +tester efficacement. Pour reprendre l'exemple de bioperl-run, cela rends sa +construction impossible sur le portage armel tant que t-coffee y défectueux sur +armel. -Deuxièmement, cela ne fournit pas un moyen simple à l'utilisateur de tester un -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 bâtir 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 ne s'en sert que de manière optionnelle. +Deuxièmement, ça n'est pas suffisant si on veut permettre aussi à l'utilisateur +de tester pareillement un programme installé sur son système. La proposition +[DEP 8](http://dep.debian.net/deps/dep8/), dont le but est de tester au moment +de la construction les programmes tels qu'ils sont empaquetés, est un pas dans +une bonne direction. Peut-être ce système pourra-t-il être étendu pour qu'on +puisse aussi tester les paquets binaires. Cela permettrait aussi de faire les +tests non pas au moment de la construction, mais juste après, et ainsi profiter +de la plus grande flexibilité des relations de dépendances entre paquets +binaires, pour éviter qu'un seul programme manquant n'invalide complètement un +paquet qui ne s'en sert que de manière optionnelle.