Il y a deux semaines, j'ai mis à jour les paquets contentant les modules BioPerl bioperl et bioperl-run, ce qui a permis de continuer le travail sur GBrowse, l'un des 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é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. Ils sont néanmoins exécutables en utilisant la variable d'environnement DEB_MAINTAINER_MODE 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 sa branche de dévelopment. Au contraire, BioPerl-Run échoue sur les tests Bowtie, DBA, EMBOSS, Genewise, 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 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 portages autres que ceux utilisées par l'empaqueteur (amd64 dans mon cas). Même les plus simples peuvent être utiles. Dans le cas de T-Coffee, qui fournit un test rudimentaire que j'ai activé récemment, cela a montré que les paquets distribués actuellement pour armel 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 chaque portage via les journaux de construction. 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. Deuxièmement, cette approche n'aide pas l'utilisateur à tester pareillement un programme installé sur son système.

La proposition DEP 8, pour tester des paquets binaires avec du matériel fourni par leurs paquets source, va peut-être régler ces deux problèmes.