Parrainer un paquet signifie l’uploader pour le compte d’une autre personne (qui se trouve être, la plupart du temps, un nouveau contributeur voulant devenir mainteneur de paquet). Le parrainage est réservé aux développeurs Debian, car ils sont réputés connaître les tenants et aboutissants de l’empaquetage. Cet article essaye ici de documenter ce processus, afin de s’assurer que le parrain effectue un travail satisfaisant, au regard des standards Debian.

Parrainer un paquet dans l’archive Debian n’est pas une tâche triviale. Cela suppose que vous ayez vérifié son empaquetage et jugé qu’il était du niveau de qualité attendu par Debian. Voyons voir ce que vous pouvez et devriez faire dans un tel cas :

Parrainer l’envoi initial

Parrainer un tout nouveau paquet requiert une analyse méthodique de son empaquetage : compiler le paquet et tester le logiciel proprement dit n’est absolument pas suffisant ! Vous devez ouvrir chaque fichier dans le répertoire debian à la recherche de problèmes potentiels. Voici une liste que vous pouvez utiliser pour réaliser cet audit :

• Vérifier que l’archive TAR amont fournie est identique à celle distribuée par l’auteur amont (dans le cas où les sources ont été ré-empaquetées pour Debian, il vous faudra générer l’archive par vous-même) ;
• Lancer lintian. Ce dernier remontera beaucoup de problèmes « habituels ». Vérifier que les overrides employés pour masquer des erreurs sont pleinement justifiés ;
• Lancer licensecheck et vérifier que debian/copyright est correct et exhaustif. Rechercher les problèmes de licences (comme les fichiers dont l’en-tête comporte « All rights reserved », ou une licence non compatible avec les principes du logiciel libre selon Debian) ;
• Compiler le paquet avec pbuilder (ou équivalent), afin de s’assurer que les dépendances de compilation soient complètes ;
• Rechercher les erreurs dans debian/control : est-ce qu’il suit les bonnes pratiques ? Est-ce que la liste des dépendances est complète ?
• Rechercher les erreurs dans debian/rules : est-ce qu’il suit les bonnes pratiques ? Est-il améliorable ?
• Rechercher les erreurs dans les scripts de configuration (preinst, postinst, prerm, postrm, config) : est-ce que les scripts preinst et postrm fonctionneront si les dépendances ne sont pas installées ? Est-ce que tous les scripts sont bien idempotents (c’est à dire qu’ils peuvent être lancés un nombre arbitraire de fois sans conséquences fâcheuses) ?
• Passer en revue toutes les modifications faites aux fichiers amont (soit dans les fichiers .diff.gz, soit dans debian/patches/ ou directement embarquées dans le tarball debian en ce qui concerne les fichiers binaires). Est-ce que ces modifications sont justifiées ? Sont-elles proprement documentées (en utilisant DEP-3 dans le cas des patchs) ?
• Pour chaque fichier, il vous faut vous demander pourquoi il est là et s’il constitue la meilleure manière d’atteindre le but recherché. Est-ce que le mainteneur suit bien les bonnes pratiques de l’empaquetage décrites dans la Référence du Développeur Debian ?
• Compiler, installer les paquets, et essayer les logiciels. Assurez-vous de pouvoir supprimer et purger les paquets. Vous pouvez aussi tester les paquets grâce à piuparts.

Si cet audit n’a révélé aucun problème, vous pouvez alors uploader le paquet. Mais souvenez-vous que même si vous n’en êtes pas le mainteneur, le parrain reste responsable de ce qu’il a envoyé dans l’archive Debian. C’est pourquoi vous êtes encouragé à suivre le paquet grâce au PTS (Package Tracking System – Système de Suivi des Paquets).

Parrainer la mise à jour d’un paquet déjà existant

Vous supposerez généralement que le paquet a déjà été l’objet d’un examen minutieux. Donc plutôt que de recommencer, vous analyserez avec beaucoup d’attention les différences entre l’ancienne et la nouvelle version préparée par le mainteneur. Si vous n’avez pas vous-même effectué la revue initiale, vous souhaiterez peut-être jeter un coup d’oeil un peu plus approfondi au paquet en lui-même, juste au cas où le premier « relecteur » ait été un peu négligeant.

Pour comparer, il vous faut les deux versions. Télécharger la version source actuelle (grâce à apt-get source) et recompiler-là (ou télécharger le fichier binaire correspondant : aptitude download). Télécharger ensuite le paquet source à parrainer (la plupart du temps via dget).

Lisez les nouvelles entrées du fichier de suivi des modifications (changelog) : il devrait vous dire à quoi vous attendre. L’outil principal que vous allez utiliser est debdiff, que vous pouvez lancer avec deux paquets sources (fichiers .dsc) ou deux fichiers binaires, ou encore deux fichiers .changes (il comparera alors tous les fichiers binaires listés dans les fichiers .changes).

Si vous comparez les paquets sources (en excluant les fichiers upstream dans le cas d’une nouvelle version upstream, par exemple en filtrant la sortie de debdiff grâce à filterdiff -i '*/debian/*'), vous devez comprendre toutes les modifications qui s’affichent, et elles doivent être proprement documentées dans le suivi des modifications Debian.

S’il n’y a rien à relever, compiler le paquet et comparer les fichiers binaires, afin de vérifier que les modifications vues dans les sources n’ont aucun effet de bord (comme des fichiers supprimés par erreurs, des dépendances manquantes, …).

Il peut également être utile de contrôler l’état du paquet sur le PTS, histoire de vérifier que le mainteneur n’a rien manqué d’important : peut-être que des traductions en attente auraient pu être intégrées, ou bien le paquet a fait l’objet d’une mise à jour indépendante (NMU – Non-Maintener Upload) mais le mainteneur a oublié d’en reprendre les modifications dans sa nouvelle version. Il se peut également qu’un bogue critique pour la publication ait été laissé de côté et bloque la migration vers testing… bref : quelle qu’en soit la nature, si vous trouvez quelque chose qui aurait pu être (mieux) fait, il est temps de le dire au mainteneur de sorte à ce qu’il puisse s’améliorer la prochaine fois, et qu’il ait plus justement conscience de ses responsabilités.

Si vous n’avez trouvé aucun problème, alors il est temps d’uploader la nouvelle version. Dans tous les autres cas, demandez au mainteneur de vous envoyer une version corrigée.

Cet article a servi de base à la rédaction de la section correspondante de la Référence du développeur Debian (cf #453313). Cliquez ici pour soutenir mon travail sur la documentation Debian.

Ceci est une traduction de mon article Best practices when sponsoring Debian packages contribuée par Weierstrass01.