Un bel outil présenté par Imil ce samedi, alors j’espère que mes notes seront à la hauteur !
Le thème d’aujourd’hui est le système de gestion de packages pkgsrc, aka “Package source”. Intimement lié à NetBSD, ce système de gestion de paquets est totalement multi-plateformes (Oui oui, même avec Windows ou Mac !)
Pour les néophytes, un package permet de distribuer un logiciel de façon standardisée sur plusieurs machines. En gros, c’est un outil qui va non seulement installer le bout de soft dont on a besoin, mais aussi les autres composants (pages de manuels, fichiers de conf, etc.) et faire les tâches annexes nécessaires (Gestion des droits, Création d’un utilisateur dédié, par exemple …). Bref, les packages, ça sert à ne pas faire des installations artisanales, et donc à gérer toutes ses machines de façon strictement uniforme. Vous en utilisez sûrement un sur votre système : apt, yum ou portage … Ça dépend de vos préférences (Je suis pas raciste, j’ai un ami qui utilise le gestionnaire de packages windows T.T).
Cependant, en 1994, FreeBSD introduit les ports, un système de packages basé sur les sources qui permet à chacun d’installer des applications en les recompilant sur sa plateforme et non pas en récupérant un binaire pré-compilé. L’idée est bonne, les gens de NetBSD la forkent et en font un système universel (C’est à dire Multi-OS) : pkgsrc en naitra !
Premier contact avec pkgsrc
Si pkgsrc est particulièrement associé à l’univers de NetBSD, il fonctionne totalement sur les autres OS. C’est d’ailleurs là son point fort, visiblement. Je vais donc voir en même temps que je tape ces notes comment l’utiliser sous Linux.
Installation (en bootstrap, sous Linux)
Sous NetBSD, l’arborescence associée à pkgsrc se trouve dans le répertoire /usr/pkgsrc. C’est normal, car il s’agit du système propre à cette distribution. Sous Linux, on peut le placer où l’on veut tant que ça n’interfère pas avec le système de packages existant.
Pour me mettre dans un contexte pas trop compliqué, je vais faire une installation de type “bootstrap”, c’est à dire dans mon répertoire home et sans utiliser les droits root.
Au lieu de s’installer dans /usr/pkgsrc, pkgsrc sera dans /home/rancune/pkgsrc :
Oui, ça utilise CVS … Si vous ne l’avez pas, il faudra l’installer ou alors passer par git (github.com/NetBSD/pkgsrc)
Les lignes défilent (le temps que CVS fasse son job), et vous vous retrouvez avec un zoli répertoire pkgsrc de 1.2G (Pour un système de packages, ce n’est pas si gros!)
En voici le contenu :
Comme on peut le voir, le “catalogue” des applis disponibles est sous forme de répertoires, correspondant à des catégories. Si par exemple on va visiter la catégorie “biology”, on y retrouve un répertoire par logiciel.
Ceci dit, l’installation n’est pas terminée. Pour préparer pkgsrc, on lance alors le script “bootstrap”, dans notre cas avec l’option unprivileged car nous ne souhaitons pas que les installations se fassent sur le système.
Cette commande va avoir deux effets :
Un répertoire /home/rancune/pkg est créé.
bmake, la version BSD de make, est compilée et installée dans ce dernier.
Tout cela se termine sur le message suivant :
Comme je suis un garçon obéissant, je rajoute donc les deux lignes suivantes dans mon bashrc :
Après avoir redémarré mon bash, je peux vérifier que cela semble fonctionner avec la commande pkg_info, qui liste les packages installés :
On notera la présence (installation automatique) de bmake : pkgsrc dépend de bmake et nécessite donc son installation ! Sous Linux, il faudra prendre bien garde à l’utiliser en lieu et place de (gnu)make.
Le répertoire pkg qui s’est créé contient d’ailleurs tous les répertoires habituels : bin, sbin, etc … C’est l’environnement dans lequel seront installés tous les softs fournis par pkgsrc. Pas de mélange avec le système, pas de conflit, pas de risque. J’aime bien ça !
Bon, l’installation de pkgsrc est finie … On joue ?
La configuration de pkgsrc
La configuration de pkgsrc se trouve dans le fichier etc/mk.conf
Comme nous somme sur un système bootstrappé, cela sera donc :
/home/rancune/pkg/etc/mk.conf
C’est ici que nous pourrons affiner un peu nos réglages en termes de compilations : CFLAGS, LDFLAGS et autres joyeusetés.
Bon, et si on essayait d’installer quelquechose maintenant ?
Un exemple ?
Pour tester pkgsrc, nous allons installer l’utilitaire pkgfind, un outil de recherche parmi les paquets disponibles. On commence par se déplacer vers le bon répertoire :
Comme on peut le voir, le contenu du répertoire n’est pas trop complexe. Il contient principalement un Makefile comprenant la recette pour compiler notre logiciel.
Nous allons procéder à ladite compilation avec bmake :
Comme on peut le voir, les différentes étapes de la compilation se font dans le repertoire work/, créé à cet effet.
Il ne reste plus qu’à installer notre soft, encore une fois à l’aide de bmake :
Notre programme est maintenant installé dans /home/rancune/pkg.
Si c’est pas la classe ça … \o/
Installer directement des binaires avec pkgin
Si on ne veut pas tout recompiler, on peut également utiliser un outil permettant de télécharger directement des binaires et de les installer : pkgin !
(Preuve de qualité du logiciel, le nom d’un certain Imil apparaît dans les commits du projet … ^^)
Car nous ne sommes pas condamnés à toujours tout recompiler, il existe des build farms, qui vont faire le boulot et fournir des repositories de binaires. Parmis celles-ci, on peut notamment citer la société joyent qui fournit des binaires pour Mac, Linux, SmartOS et NetBSD !
Voici quelques commandes de bases :
Pour mettre à jour la liste des paquets disponibles:
Pour installer un package ( ici screen ):
Pour rechercher un package :
Pour avoir un easter egg (bah quoi ? c’est important!)
Un peu comme apt, pkgin se configure au travers du fichier :
/home/rancune/pkg/etc/pkgin/repositories.conf
qui permet de choisir les repos que l’on souhaite utiliser.
Packageons un peu … pkgsrc-wip !
Il est maintenant temps de nous exercer à faire notre propre package, et devenir un peu plus actifs dans cette belle communauté.
Le projet pkgsrc-wip (Work in Progress) est un repo permettant de se “faire la main”. On y obtient l’accès après avoir montré patte blanche (Ca semble assez simple) et ça permet de soumettre ses propres paquets à la communauté. Après 10, 20 … 30 commits, vous serez peut-être remarqués et on vous proposera peut-être de rejoindre le projet officiel, qui sait ?
En tout cas, pour suivre cette voie, il faut commencer par cloner le repo git au bon endroit :
Pour ça, pas besoin de permission.
Nous allons packager un superbe logiciel, mis au point par Maître Imil himself ! Il est disponible dans le repo gitlab suivant :
(Imil, dans sa grande sagesse, a taggué la version qui nous intéresse du doux nom de “v1.0”. Prenez la bonne version, c’est important !
Ce repo contient trois fichiers :
truefalse.c
un fichier Makefile (pour bmake)
un README.md
Les pré-requis
Avant de commencer, il va tout d’abord falloir indiquer à pkgsrc que nous sommes dévelopeur. Oui, c’est ici que le syndrôme de l’imposteur revient frapper à la porte, mais vous allez voir, ca va bien se passer.
Pour ce faire, on édite le fichier etc/mk.conf et on ajoute la ligne suivante :
On installe ensuite le meta-package pkg_developer qui ramène tout ce dont nous allons avoir besoin pour ce nouveau job (Tu les sens arriver les responsabilités ? La pression qui monte ???)
(Vous pouvez aller prendre un café, ça compile un moment !)
Si vous vous ennuyez pendant la compilation, vous pouvez préparer le répertoire pour notre package en attendant :
Playskool présente : mon premier package !
L’outil url2pkg, installé précedemment par pkg_developer, va nous construire un template de package à partir d’une simple url au format tar.gz :
Oooooh ! Un Makefile !!!
Nous allons visiter un peu les différents fichiers, en commençant par le Makefile:
Comme on peut le voir, il est relativement simple et comprend quelques blancs que nous allons renseigner.
Le champs PKGNAME, par exemple, contient le nom du package. Il est construit par une regexp à partir du DISTNAME en retirant le numéro de version.
Le champs CATEGORIES, lui, doit contenir la catégorie dans laquelle nous souhaitons ranger notre soft. Pour choisir, il suffit de sélectionner l’un des répertoires de /home/rancune/pkgsrc que nous avons vus plus haut.
Pour LICENSE, nous allons procéder de même. La liste des licences se trouve dans /home/rancune/pkgsrc/licenses, tout simplement. Le fichier mk/licenses.mk permet de voir quelles licences sont valides et comment.
Une fois rempli, notre fichier Makefile ressemble à cela :
Si on veut le compléter, tout un ensemble d’outils est disponible dans le répertoire mk de pkgsrc. Cela vaut le coup d’aller y faire une petite visite !
Le fichier DESCR, quand à lui, contient une description de notre paquet.
Il est automatiquement rempli à partir du README.md de notre repo git, il n’y a qu’à adapter un peu !
Le fichier distinfo contient les hashs BLAKE2s et SHA512 du fichier tar.gz contenant les sources. Il permettra à pkgsrc de les vérifier avant la compilation et l’installation.
Et pour finir, PLIST contient une liste des fichiers qui seront installés sur le filesystem par notre paquet. Pour le moment, c’est un template vide :
Nous allons le remplir bientôt !
On peut maintenant vérifier que nous avons bien fait les choses avec l’outil pkglint, qui permet de valider un package :
Puisque tout est bon, nous pouvons commencer à voir si notre package compile bien :
C’est beau quand ca marche !
Si vous êtes curieux, vous pouvez aller voir dans le répertoire work/ qui vient de se créer. Vous y retrouverez les différentes étapes de construction.
Installation
Avant de lâcher notre package dans la nature, il serait de bon ton de vérifier comment et où il va s’installer :
Ici, le prefix d’installation est work/.destdir … et on voit qu’il va nous placer l’executable directement en haut !
Nous allons donc modifier un peu le Makefile pour corriger cela :
L’ajout de la cible do-install que nous faisons dans le Makefile est nécessaire parce que l’auteur du soft que nous packageons n’a pas mis en place de cible d’installation dans son projet (make install ne marche pas). Sinon, Cela marcherait tout seul sans que l’on ait besoin de faire quoi que ce soit !
On met également à jour le fichier PLIST:
Et on reteste …
Nickel :)
Cette fois-ci on y va pour de vrai:
Ça marche !!!!!!!!!!!!!!!!!
Oui, mais le gars qui a écrit ce soft a fait quelques erreurs … Au programme du prochain épisode, nous allons proposer un patch upstream et voir comment on fait !
Le mot de la fin …
Bien que je sois beaucoup plus familier de portage, sous gentoo, le duo pkgsrc/pkgin me semble bien sexy ! De façon générale, les packages installés par ces deux outils sont un univers autonome et distinct du reste du système. Il n’y a donc aucun risque que je fasse une bêtise, comme cela m’est souvent arrivé à mes débuts.
J’avoue, j’ai hâte d’en voir la suite :)
Rancune.
La bibliographie :
Une vieille présentation écrite par Imil, pour le FOSDEM 2012: