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.
projects / source.git / commitdiff