pkgsrc (2/6)
Et nous voici repartis pour une nouvelle prise de notes sur les streams d’Imil ! Nous continuons, dans cette vidéo à découvrir le système pkgsrc et la vie de mainteneur de package.
Previously on Imil TV …
Commençons par un petit rappel de ce que nous avions vu la dernière fois. Intéressés par un soft disponible sur gitlab, truefalse v1.0, nous nous sommes dit que nous allions le packager avec pkgsrc …
Pkgsrc, c’est un système de gestion de packages made in NetBSD et basé sur bmake. Il fonctionne sur de nombreuses autres plateformes, parmi lesquels on notera Mac OSX ou même windows ! Les commandes présentées ici sont d’ailleurs testées sous gentoo par votre serviteur :)
Nous avons commencé notre épopée dans le monde des mainteneurs de package en utilisant un outil appelé url2pkg, permettant de transformer une url en package :
On obtient un Makefile, que l’on modifie un peu :
Habituellement pour compiler un package, on utilise la commande ./configure, qui génère un Makefile possédant une target install. On lance alors un simple :
Mais dans le projet que nous sommes en train de packager, le Makefile n’est pas super évolué . C’est un Makefile bmake très simple, qui ne comporte pas de cible d’installation.
C’est pour cette raison que nous avons surchargé la target do-install dans notre package. D’où ces lignes en particulier :
A ce stade, un petit rappel est peut-être nécessaire concernant les variables DESTDIR et PREFIX. Le PREFIX, vous en avez probablement l’habitude si vous avec déjà manipulé les autotools et le célèbre script “configure”. En effet, par défaut, ce script configure utilise un prefix qui vaut “/usr/local” pour effectuer les installations. Cela permet de choisir le chemin de base de l’installation : les binaires iront dans /usr/local/bin, les librairies dans /usr/local/lib et ainsi de suite … Si on veut déployer le soft ailleurs, dans /usr par exemple, il suffit de modifier la variable PREFIX.
Pkgsrc introduit une seconde variable, DESTDIR, qui va nous permettre de “simuler” une installation dans un répertoire grâce à la cible stage-install. Si on tape :
L’installation ne va pas se faire de façon habituelle mais localement, dans le sous-répertoire work. C’est très pratique pour pouvoir vérifier les destinations d’installation de notre package.
Lorsque nous tapons “bmake install”, DESTDIR vaut “/”.
Lorsque nous tapons “bmake stage-install”, DESTDIR vaut “/home/rancune/pkgsrc/wip/truefalse/work”.
Tout simplement !
pkgsrc et ses targets
Un petit mot sur les différentes cibles proposées par pkg-src. Il en existe un certain nombre et elles sont plutôt pratiques ! Le lecteur intéressé pourra se rendre sur :
https://wiki.netbsd.org/pkgsrc/intro_to_packaging/
En voici une petite sélection :
- bmake stage-install
Permet une simulation de l’installation dans un répertoire local au package, comme vu ci-dessus.
- bmake print-PLIST
Liste des fichiers du paquet installés sur le filesystem
- bmake clean
Efface le fichier source du répertoire de travail, pour repartir d’un projet tout propre !
- bmake distclean
Efface l’archive source téléchargée
- bmake fetch
Récupère le fichier, et vérifie si son checksum correspond à celui enregistré
- bmake extract
Extrait (décompresse) les fichiers sources de l’archive et les place dans le répertoire de travail
- bmake patch
Applique les patchs (du package) aux sources
- bmake show-depends
Permet de visualiser les dépendances du package, s’il y en a :
- bmake show-options
Les packages peuvent parfois avoir des options, c’est à dire des fonctionnalités que l’on peut choisir de compiler ou pas lors de l’installation dudit package. Pour consulter ces options, on procède de la façon suivante :
Comme indiqué par le message affiché, la selection des options se fera par la variable PKG_DEFAULT_OPTIONS pour des choix généraux, et par la variable PKG_OPTIONS.<package> pour un package en particulier.
Ceci se fait dans le fichier mk.conf, qui contient la configuration de pkgsrc.
- make show-var VARNAME=<variable>
Permet de consulter la valeur d’une variable utilisée dans pkgsrc.
Avis personnel, je suis de plus en plus convaincu par pkgsrc. Je trouve le système particulièremenr efficace, pas vous ?
Revenons maintenant à notre initiation dans la voie du packageur :)
Ecrire un patch :
Nous retournons maintenant à notre package, et à notre projet truefalse v1.0. On recompile le projet, afin de revenir au même point que la semaine dernière :
Lorsque nous avions testé ce programme, nous nous étions rendus compte qu’il ne fonctionnait pas correctement : lancé sans argument, le programme renvoie false !
Et Pour cause :
On voit le bug : le test devrait être (arc<2) et non pas (argc<1) !
En tant que packagers, nous décidons de corriger le bug, et de proposer upstream (aux développeurs du projet original) un patch corrigeant cette petite erreur !
On commence donc par extraire les sources de truefalse :
Dans le meta-package pkg-developer que nous avons installé la dernière fois, il y a un outil qui claque : pkgvi !
pkgvi ouvre une fenêtre vim pour éditer le code, et crée tout seul le truefalse.c.orig contenant le code avant modification. C’est pas le luxe ça ?
Pour créer le patch, on fait encore une fois appel à pkgsrc, et à la commande mkpatches
Un nouveau repertoire, “patches”, s’est créé. Il contient notre patch. Néanmoins ce nouveau fichier est absent de notre liste de fichiers contenue dans distinfo. Pour l’y ajouter, on utilise la cible makepatchsum, aussi abrégée mkps :
Notre nouvelle version du package, incluant le patch, est prête ! il ne reste plus qu’à la tester :
On voit bien que le patch est appliqué ! Et si l’on teste, notre programme fonctionne désormais !
Fiers comme des paons (et franchement, il y a de quoi non ?), nous pouvons soumettre notre patch upstream. Car, et c’est une partie importante du message d’aujourd’hui, le packageur joue un rôle important dans le développement d’une application en y participant activement. Il n’est d’ailleurs pas rare qu’un packageur “adopte” un projet laissé à l’abandon par ses développeurs, mais dont sa communauté a besoin !
Ce n’est pas sans joie que nous voyons apparaître une [version 1.1][https://gitlab.com/iMil/truefalse/-/commits/v1.1] de truefalse, intégrant notre patch … \o/
Sortie de truefalse v1.1 ? On y va !
Puisque la version 1.1 est sortie, nous allons mettre à jour notre package. Je vous entends déjà : “Quoi ?? Faut tout refaire ?” Que nenni ! Avec pkgsrc, ceci va se faire sans douleur !
On commence donc pas modifier notre Makefile pour passer à la version 1.1. Quitte à y être, on en profite pour mettre le numéro de version dans une variable VERS, ça évitera les carabistouilles !
Désormais, ce sont bien les sources de la version 1.1 qui seront utilisées :
On remet à jour le fichier distinfo, afin que les checksums de cette nouvelle version y soient intégrés :
Nous allons également pouvoir retirer notre patch du package, puisqu’il a été intégré upstream. Il ne faut alors pas oublier de retirer également les checkums des patchs du fichier distinfo :
On teste … et ça fonctionne !!!
You have new mail
Une nouvelle journée s’offre à vous : les oiseaux chantent, le soleil brille, ça sent bon le café dans le bureau … Et vous recevez un nouveau mail : OOOOOOh, une version 2.0 de true false est sortie !
Vous jetez un coup d’oeil aux sources, et là c’est le drame :
Mais … mais … mais ???? Pourquoi ??? Notre développeur a décidé d’utiliser la glib ?????
Et ce Makefile, là : pourquoi abandonner bmake ? On utilise la version Gnu de make maintenant ????
Il va falloir gérer tout ça … Mais ce sera dans la prochaine vidéo !
A très bientôt,
Rancune.