Créer un paquet NetBSD pour Fabric

Le hasard faisant bien les choses - surtout quand on lui demande gentiment - iMil s'est fendu dans le précédent opus de notre revue préférée d'un article d'introduction sur l'utilisation dudit outil.

Curieux, j'ai eu envie de tester. Mais je n'avais aucune envie de semer le dawa dans mon ${PREFIX}, et je souhaitais surtout pouvoir désinstaller et réinstaller proprement Fabric de mon système. Il fallait donc packager proprement Fabric pour pkgsrc. C'est là tout le sujet de cet article.

1. Démarrage

Le démarrage est très classique, nous l'avons vu la dernière fois (http://www.unixgarden.com/index.php/administration-systeme/netbsd-s01e04-construire-ses-paquets-pour-pkgsrc). On exécutera donc la commande :

pour créer la trame de notre package :

Le fichier qui va consacrer toute notre attention est le Makefile :

Il convient de le compléter, ainsi que le fichier de DESCRiption du package, qui ne peut pas rester vide. On peut ensuite lancer une première fois la compilation pour mesurer « l'étendue des dégâts ».

2.Premiers ajustements...

… et premier dilemme.

Sous NetBSD, les paquets de modules Python sont préfixés de 5 caractères, de la forme, par exemple, py25- si l'application ou le module a été construit avec la version 2.5 de l'interpréteur Python. La première version du Makefile comportait donc la directive suivante :

Le contenu de la variable PYPREFIX étant automatiquement remplacé par la version de l'interpréteur utilisée pour la compilation de l'application. Ceci ne s'applique toutefois pas pour les applications. J'ai donc finalement décidé de fixer le nom du package à la valeur fabric-0.9.0, grâce à la directive suivante :

L'instruction S:/F/f/ est la syntaxe make (http://netbsd.gw.com/cgi-bin/man-cgi?make++NetBSD-5.1) pour transformer le F majuscule en f minuscule.

On renseigne la ou les catégorie(s) (CATEGORIES) correspondant à notre outil (j'avais initialement choisi www, pour changer pour sysutils et net après réflexion), ainsi que le site (MASTER_SITES) à partir duquel on peut télécharger le code. On renseigne aussi le MAINTAINER (moi-même), la HOMEPAGE, un commentaire d'une ligne précisant ce que fait cet outil, ainsi que la licence. Les licences disponibles et utilisables dans pkgsrc sont regroupées dans le répertoire ${PKGSRCDIR}/mk/licenses.

Dans le cas de Fabric, la licence est assez simple :

Licence facilement reconnaissable : il s'agit d'une licence BSD à 2 clauses. On renseignera donc la directive LICENSE ainsi :

À ce stade, le Makefile ressemble à ça :

3. Pythonons un peu (mais rien qu'un tout petit peu)

À ce stade, si on effectue un make install, on obtient un résultat assez décevant :

Vous aurez, comme moi, noté le make: cannot open Makefile. Soit. Nous allons y remédier.

3.1 Oeufs, modules et applications

Dans pkgsrc, l'infrastructure de build prend en compte 3 types différents d'applications Python :

- les eggs, qui sont en fait des « packages » Python, installables avec une simple commande easy_install mypythonegg.egg. Les eggs sont très similaires aux paquetages des systèmes d'exploitation.

- les modules, qui sont des bibliothèques de code Python distribuées sous forme « non-egg ».

- les applications, qui le plus souvent se configurent classiquement à la ./configure, make, make install.

Dans le cas de Fabric, le code est distribué sous la forme d'un Egg. En témoigne la présence du fichier Fabric.egg-info à la racine du répertoire, dans lequel ont été extraites les sources de l'outil. On va donc indiquer à pkgsrc que pour compiler Fabric, il doit considérer la compilation d'un Egg, en incluant à la fin du Makefile la directive :

On reteste, sans oublier au préalable de lancer un make clean pour nettoyer le répertoire de compilation :

Aïe. pkgsrc se plaint de ne pas trouver les fichiers installés dans la PLIST. Et pour cause, la PLIST créée initialement par url2pkg est vide. On corrige par la commande :

et on relance la compilation :

On aura remarqué les 3 warnings à la fin de la compilation. Les fichiers Python rng.py, rng_posix.py et rng_win32.py ont une valeur hardcodée pour l'interpréteur Python, différente de celle en vigueur dans NetBSD. Sous NetBSD, l'interpréteur Python 2.5 s'appelle ${PREFIX}/bin/python2.5 et non /usr/bin/python.

À ce stade de l'article, il me semble opportun de préciser quelques variables à utiliser absolument lorsqu'on travaille avec pkgsrc. En effet, le lecteur attentif aura noté l'utilisation de la variable USE_DESTDIR=yes dans les différentes commandes make utilisées dans cet article. Ceci est notamment destiné à pouvoir utiliser pkgsrc avec un utilisateur non privilégié, et est maintenant le comportement par défaut. Pour ma part, j'ai créé un alias de la forme msi='make USE_DESTDIR=yes stage-install' dans mon .zshrc pour appeler simplement la commande make avec les bons arguments. De même, on pourra activer la variable PKG_DEVELOPER et la positionner à yes, ce qui aura pour effet de déclencher plusieurs vérifications supplémentaires au cours de la création de paquets, afin d'éviter un certain nombre d'erreurs récurrentes dans pkgsrc.

Revenons maintenant à notre problème d'interpréteur Python.

4. Dilemmes

À ce stade, 2 solutions s'offrent à moi. Les fichiers fautifs se trouvent dans les sources de paramiko, une implémentation SSH pour Python. paramiko, en tant que module Python, est disponible et maintenu dans pkgsrc, dans security/py-paramiko. Je peux donc :

- soit décider de patcher les chemins de l'interpréteur Python dans la distribution de paramiko incluse avec Fabric ;

- soit décider d'utiliser le module paramiko tel que présent dans pkgsrc.

Après avoir regardé les choix faits par d'autres distributions, Debian entre autres, j'ai décidé de packager Fabric en utilisant le module paramiko fourni dans pkgsrc. Pour ce faire, il faut ajouter une dépendance sur security/py-paramiko dans le Makefile, et supprimer le répertoire paramiko des sources de Fabric une fois extraites, ce qui se traduit par le Makefile suivant :

5. Testez, testez, testez !

Nous ne devrions plus être très loin du but. Il faut nettoyer le répertoire de travail, recompiler, et ajuster la PLIST suite à la suppression du module paramiko.

Reste ensuite à tester l'installation du paquet dans toutes les situations : avec et sans DESTDIR, en utilisateur et en root, avec ou sans paquet binaire, …, pour être bien sûr que rien n'a été oublié. À un moment, d'ailleurs, il ne faudra pas oublier de vérifier qu'au-delà de la compilation, l'exécution du binaire se passe convenablement. Ce qui nous réservera une désagréable surprise :

Damn ! Une stacktrace Python ! D'après le message en dernière ligne, un des packages pré-requis à l'utilisation de Fabric, pycrypto, n'est pas trouvé. Après quelques recherches, le paquet en question s'appelle en réalité py-amkCrypto dans pkgsrc. Le problème a déjà été rencontré, notamment dans security/py-paramiko, où il a été corrigé par un patch supprimant la gestion des dépendances par les setuptools de Python.

6. Patchons !

Nous allons donc écrire ce patch proprement. La procédure de patch de fichier dans pkgsrc est extrêmement simple. On commence d'abord par installer le package pkgtools/pkgvi, qui fournit tous les outils nécessaires pour créer les patches convenablement. Pour créer le patch proprement dit, on lance la commande suivante :

pour commenter la ligne 19 dudit fichier. Une fois le fichier sauvegardé, on crée le patch pour pkgsrc par la commande :

qui va donc créer le fichier patch-aa dans le sous-répertoire patches, créé pour l'occasion.

Dernière étape, mettre le fichier distinfo à jour, ce qui se fait très facilement par la commande :

Notre patch est maintenant terminé et intégré dans le processus de compilation. Notez toutefois qu'il est possible que l'application d'un patch sur le code d'un programme ait des conséquences sur la PLIST.

Le programme Fabric, et son invocation « fab », est maintenant compilable et fonctionnel sur NetBSD.

7. La touche finale

Pour s'assurer que toutes les bonnes pratiques sont bien respectées lors de la création d'un paquet dans pkgsrc, Roland Illig a écrit un « vérificateur », appelé pkglint (pkgtools/pkglint). Cet outil, en Perl, vérifie le package en cours de création et nous informe si quelque chose n'est pas fait dans les règles de l'art. Invoqué sans paramètres, pkglint effectue une première vérification et trouve 2 erreurs :

Le Makefile doit être formaté en colonnes de 80 caractères, et la DESCRiption de l'outil doit être adaptée en conséquence. Les espaces en fin de ligne sont également à proscrire.

pklint possède également des niveaux de vérification bien plus exigeants, lorsqu'il est appelé avec les paramètres Wall (affiche tous les warnings) et Call (effectue tous les tests). L'invocation de pkglint avec ces 2 paramètres permet d'anticiper la plupart des erreurs de packaging, et uniquement celles-ci. pkglint n'est en aucun cas garant du bon fonctionnement du programme, celle-ci est de votre ressort.

La première NOTE est simple à corriger, il suffit de remplacer les espaces par une ou deux tabulations. pkglint s'assure également que la documentation est correctement installée, et en particulier qu'à chaque binaire installé est associée la page de man correspondante. Dans le cas de Fabric, ce n'est pas le cas, la page de man est manquante, ce que pkglint ne manque pas de nous faire remarquer. Enfin, il est fortement recommandé d'inclure un commentaire expliquant la raison de l'existence d'un patch. Ceci permet entre autres de différencier les patches spécifiques à pkgsrc des patches destinés à corriger des erreurs dans l'application.

Le patch commenté a l'allure suivante :

8. Et la documentation, alors ?

Comme pkglint nous l'a fait remarquer, notre package ne comporte aucune documentation. La distribution de Fabric n'incluant pas de page de man, j'ai récupéré celle du package Debian, assez sommaire. Cette page, qui se trouve en dehors de la distribution, est stockée dans le sous-répertoire files. Quant à la documentation de Fabric, elle est fournie au format ReST dans le sous-répertoire docs. Ce format peut ensuite être converti en différents autres formats (HTML, par exemple) au moyen des outils fournis dans le package textproc/py-docutils. Toutefois, je ne souhaitais pas faire ajouter une dépendance sur py-docutils dans Fabric. J'ai donc volontairement choisi de ne pas convertir la documentation de Fabric, le format ReST étant finalement un format texte parfaitement lisible sans outil extérieur.

L'installation de la documentation s'effectue à l'aide des directives suivantes dans le Makefile :

On utilise les macros INSTALL_ pour installer la page de man et les fichiers .rst aux bons endroits de l'arborescence. Les répertoires de destination devant préalablement exister dans l'arborescence, on ajoutera un peu avant dans le Makefile les directives suivantes :

pour créer les différents répertoires nécessaires. Pensez à mettre la PLIST à jour avant de continuer ! Notre paquet est maintenant prêt à être installé et testé.

Ça a l'air de marcher (au moins en local). Vous pouvez vous référer à l'article d'iMil dans le précédent numéro pour en connaître plus sur le fonctionnement de Fabric. Nous sommes prêts pour l'import, que ce soit dans pkgwrc-wip ou dans le dépôt officiel. Mais avant, une dernière vérification s'impose :

Avant l'import, j'ai toutefois remanié l'installation de la documentation avec une directive plus concise, similaire à ce qui est fait pour textproc/asciidoc, comme illustré ci-dessous :

Au lieu de copier les fichiers répertoire par répertoire comme dans la version précédente, on crée une archive pax avec tous les fichiers de documentation que l'on extraie ensuite en place dans ${DESTDIR}${PREFIX}/share/doc/fabric. Les 2 syntaxes sont valables, la seconde est simplement plus concise que la première, plus verbeuse. Mais du coup, il ne faut pas oublier de préciser à pkgsrc que nous avons besoin de pax pour l'installation de notre package. Ceci se fait par le biais de la directive USE_TOOLS+= pax dans le Makefile.

9. Import

À l'issue de l'exercice, le Makefile ressemble à ça :

L'import pourra se faire directement dans pkgsrc-wip, à l'aide du script import-package.sh, comme décrit à l'adresse http://pkgsrc-wip.sourceforge.net/. Fabric a été mon premier import dans le dépôt officiel de pkgsrc. Après moult essais, vérifications, revérifications, tergiversations, relectures, j'ai fini par me lancer, taper la commande :

et admirer le mail http://mail-index.netbsd.org/pkgsrc-changes/2010/05/26/msg041956.html qui arrive sur la liste pkgsrc-changes. Et reprendre ma respiration aussi :)

Et finalement corriger les inévitables boulettes après l'import :

- http://cvsweb.se.netbsd.org/cgi-bin/bsdweb.cgi/pkgsrc/sysutils/fabric/Makefile?rev=1.2;content-type=text%2Fx-cvsweb-markup

- http://cvsweb.se.netbsd.org/cgi-bin/bsdweb.cgi/pkgsrc/sysutils/fabric/Makefile?rev=1.3;content-type=text%2Fx-cvsweb-markup

- http://cvsweb.se.netbsd.org/cgi-bin/bsdweb.cgi/pkgsrc/sysutils/fabric/Makefile?rev=1.4;content-type=text%2Fx-cvsweb-markup

Soupir… On mettra ça sur le dos du stress.

Epilogue

Depuis le début de la rédaction de cet article, sysutils/fabric a été mis à jour 2 fois, d'abord en version 0.9.1, puis en 0.9.3. Le packaging a commencé avec Python-2.5, avant de basculer vers Python-2.6 lorsque celui-ci est devenu la version par défaut installée dans NetBSD. L'évolution la plus notable en 0.9.3, du point de vue du packageur, a été l'abandon par les développeurs de Fabric de leur version de paramiko, incluse dans l'archive des sources de Fabric. Mon choix initial de reposer sur la version de paramiko fourni dans pkgsrc s'est donc révélé judicieux. La mise à jour de Fabric en version 0.9.3 a également vu l'ajout d'une dépendance sur security/py-crypto, qui a été préféré à security/py-amkCrypto, déjà utilisé dans paramiko, mais hélas totalement abandonné upstream.

En attendant la version 1.0 de Fabric…