NetBSD S01e03 : Gestion des paquets

1. Binaires or not binaires, that's the question

Un dilemme se présente (qui donne souvent lieu à de grands débats) : dois-je utiliser les paquets binaires ou compiler moi-même mes logiciels ? Le premier cas a déjà été évoqué ; pour le deuxième, on ne partira pas de rien. En effet, nous utiliserons pkgsrc ! Mais cela ne répond pas à la question, me direz-vous. En fait, j'aurais tendance à dire que ça dépend (une vraie réponse de Normand ;) ). Dans le cas où vous utilisez votre système de manière standard, que vous ne voulez pas perdre du temps à compiler en permanence, le choix des binaires s'impose à vous. En revanche, dans le cas où vous avez besoin d'un logiciel dont la licence ne permet pas sa diffusion sous forme de paquets binaires (flash au hasard, …) ou que vous ayez besoin d'options de configuration non standard, ou que le logiciel ne soit pas disponible déjà compilé, la compilation sera de mise.

Bon, le décor est posé, place à l'action !

2. Pkgin, suite et fin

Lors de la parution de l'article dans GLMF N°118, iMil[2] nous expliquait le fonctionnement de pkgin[3]. Or depuis, bien des suggestions et évolutions plus tard, une des fonctionnalités intéressantes est l'utilisation possible de multiples repositories. Il s'agit en fait de la possibilité de spécifier à pkgin les sources possibles de récupération des paquets binaires. A première vue, rien d'extraordinaire, si ce n'est simplement la possibilité de spécifier en plus d'une ou plusieurs sources distantes, une source locale ! Exemple :

Ici, mon $LOCALBASE est /usr/pkg/ mais nous pourrions changer cette directive. Nous verrons plus loin toute l'importance de cette nouvelle fonctionnalité de pkgin ainsi que la directive LOCALBASE.

3. Pkgsrc

3.1 Petite intro

pkgsrc[4] (package source) est le framework de packaging de NetBSD. Il vous permettra d'ajouter, d'enlever, bref de gérer les logiciels sur le système. Comme pour l'OS à la serviette orange, il a été destiné dès le départ à être portable, et de ce fait, d'autres OS l'utilisent en en ayant fait leur système de packaging par défaut comme DragonFlyBSD[5], Draco Linux[6], … Ce framework a été écrit par Alistair G. Crooks[7] (récemment interviewé par l'équipe de NetBSDfr) et a vu le jour en août 1997.

3.1.1 En quoi consiste-t-il ?

pkgsrc est organisé sous forme de répertoires regroupant en catégories les logiciels. Dans ces catégories, nous trouvons d'autres répertoires, nommés du nom de leur programme et contenant ainsi les fichiers nécessaires à leur compilation au sein du framework. 1 répertoire = 1 application. Exemple :

Nous allons regarder un peu plus en détail, mais sans rentrer dans de grandes explications, le contenu d'un répertoire, par exemple, le logiciel bunzip :

Explications :

- CVS : je passe - ce sont les informations de contrôle de CVS ;

- DESCR : ce fichier contient le descriptif détaillé du logiciel et de ses fonctions ;

- Makefile : LE fichier clé qui contient de nombreux renseignements tels le nom programme, sa catégorie, …, mais surtout toutes les spécifications nécessaires au bon déroulement de sa compilation et installation comme les dépendances, … ;

- PLIST : ce fichier contient la liste des fichiers et leurs emplacements après installation. Il renseignera la base des logiciels installés : var/db/pkg ;

- distinfo : contient les sommes de contrôle SHA1 et RMD160 des sources du logiciel ainsi que des patchs nécessaires, le cas échéant ;

- patches : ce répertoire contient les patches nécessaires à la bonne compilation du logiciel. Un fichier patch sera généré par paramètre à modifier.

Voici donc à quoi ressemble le contenu d'un logiciel au sein de l'arbre pkgsrc.

3.2 Récupérer pkgsrc

3.2.1 Récupération de l'arbre

Une fois de plus, je vais vous décrire UNE méthode parmi tant d'autres. On peut récupérer l'arbre pkgsrc par CVS, FTP, csup et même git[7]. Au départ, je préfère récupérer l'archive current de pkgsrc sur FTP pour la décompresser ensuite. Cette méthode me parait rapide, simple et efficace :

Et voilà, simple, n'est-il pas ?

3.2.1.1 Maintenir son arbre toujours vert

Notre package current l'a été de manière éphémère. En effet, l'arbre est en perpétuelle mouvement par des modifications suite à des corrections de bugs, faille de sécurité ou autres, qui pourraient corrompre l'intégrité de notre OS. Il convient donc de le maintenir à jour. Pour cela, nous avons à nouveau plusieurs choix :

- via CVS :

- via csup : avant tout il va falloir installer csup via pkgin ou simplement en récupérant le paquetage binaire directement sur un FTP :

Puis nous allons créer un fichier qui permettra à csup d'aller récupérer les changements de l'arbre et de répercuter ces changements sur notre arbre local :

Ce fichier mérite quelques explications :

- *default tag=. : permet de spécifier la branche que l'on suit, ici : la branche current de pkgsrc ;

- *default prefix=/usr : on indique l'endroit où se trouve notre arbre, ici dans /usr (on verra plus loin ce paramètre) ;

- netbsd-pkgsrc : on veut synchroniser pkgsrc.

On a installé csup, on a notre fichier de configuration qui va bien, go go go pour la synchro :

Cette opération peut prendre plus ou moins de temps en fonction de votre connexion internet bien sûr, mais également en fonction de la fréquence de mise à jour. Il est donc judicieux de « cronifier » cela.

pkgsrc est le repository maintenu par les commiters NetBSD, mais il existe également un repository nommé wip[8] (Work In Progress), ou quiconque désire s'essayer au packaging pkgsrc peut obtenir très simplement un accès. pkgsrc-wip est également utilisé par les développeurs NetBSD afin de tester un package avant de le commiter dans l'arborescence officielle. Chaque sous-répertoire de wip est un programme, il n'y a donc pas de notions de catégories à ce niveau. Pour l'installation de wip, on procède de la même manière que pour pkgsrc, on récupère un snapshot que l'on décompressera dans /usr/pkgsrc/. La synchronisation est identique à pkgsrc, on ajoutera simplement dans le fichier de configuration de csup (ici netbsd-supfile), une ligne en fin de fichier : netbsd-pkgsrc-wip et le tour est joué.

3.3 Le chef de gare annonce le départ

3.3.1 le fichier mk.conf

Bon, notre arbre va se maintenir à jour, très bien, mais que fait-on maintenant ? Avant toute chose, un des fichiers très importants de la configuration de notre système est : mk.conf. J'avais survolé son utilisation lors de l'épisode précédent et ce fichier ressemblait à cela (je ne reviendrai pas sur les explications) :

Nous allons l'enrichir et y ajouter quelques directives :

Explications :

- MASTER_SORT=.fr .uk .de : voici les serveurs à privilégier lors du téléchargement des fichiers sources ;

- PKG_RESUME_TRANSFERS=YES : si pour une raison ou une autre, le téléchargement du fichier source était interrompu, cette directive permet de spécifier au système de reprendre la récupération là où elle s'était arrêtée ;

- ACCEPTABLE_LICENSES+=vim-license : certains logiciels nécessitent un accord de la part de l'utilisateur, cette directive permet de spécifier une bonne fois pour toutes notre accord (intéressant notamment lors des mises à jour) ;

- PKG_OPTIONS.openoffice3+=firefox3 gtk2 lang-fr : certains logiciels peuvent être compilés avec plusieurs options, les options voulues sont à spécifier dans ce fichier (toujours plus pratique lors de mise à jour). La syntaxe est de la forme PKG_OPTIONS.le_nom_de_mon_logiciel+= mes_options. Ici on demande qu'Open Office 3 (oui, y a des fous qui le compilent !) soit compilé avec la dépendance de Firefox 3, du framework GTK+ 2 et en français.

Nous aurons l'occasion d'enrichir encore ce fichier au cours de l'article.

3.3.2 l'heure H

Cette fois-ci, ça y est, on est prêt. On va choisir un logiciel relativement simple pour commencer : pkgfind. Cet outil permettra de trouver très rapidement le logiciel que vous souhaitez installer dans l'arbre pkgsrc. La gestion des dépendances est implicite, si un logiciel a besoin d'un autre pour qu'il fonctionne, pkgsrc lancera la compilation de celui-ci.

La magie s'opère, les lignes de compilation défilent, pas d'erreur, pkgfind est installé ! Un petit test pour en être convaincu :

mais il existe une autre commande pour voir les logiciels installés sur le système :

Vous obtiendrez un warning lors de la compilation d'un logiciel :

On peut clairement ignorer ce message : on ignore simplement la liste des logiciels connus pour avoir eu une faille de sécurité. Dès qu'une faille est repérée au niveau d'un logiciel, celui-ci est mis à jour au niveau de l'arbre pkgsrc, d'où l'importance de le tenir à jour quotidiennement, sinon on lancera la commande comme indiqué dans la 2ème ligne du message.

On peut remarquer, dans la ligne de commande, les flags clean et clean-depends Dans cet exemple, le premier flag a été exécuté et le retour est : ==> Cleaning for pkgfind-20050804. Lors de la compilation d'un logiciel, il crée automatiquement dans le répertoire de celui-ci un répertoire work dans lequel il compile les sources. Ce flag a pour but de nettoyer ce répertoire de travail en le supprimant tout simplement. L'autre flag clean-depends ferait de même avec les répertoires work de toutes les dépendances. Pratique pour ne pas s'encombrer de fichiers inutiles. Mais bon, quand on dit que pkgsrc a bien été pensé, il existe une directive à ajouter dans notre fichier mk.conf, qui nous évitera de le spécifier à chaque installation : CLEANDEPENDS=yes donc :

et le tour est joué.

Il arrive que l'on veuille garder le répertoire work peuplé de ses fichiers (notamment les développeurs, ou alors lors de la compilation d'un logiciel important comme Open Office, Jdk, …) et que si par hasard on avait installé quelques logiciels, la commande suivante permettrait de nettoyer notre arbre :

Après pkgfind, prenons un autre exemple plus complexe, le logiciel fetchmail :

L'instruction make show-options permet de nous informer des options disponibles pour compiler fetchmail. Le message est clair, par défaut, l'option ssl est activée mais nous allons également spécifier l'option socks5 afin que le logiciel supporte ce protocole. Une fois de plus, nous allons spécifier ces options dans notre fichier mk.conf afin de ne pas avoir à renouveler l'opération lors d'une mise à jour, par exemple :

puis nous lançons la commande make clean install.

Il existe bien d'autres targets à make, je vous invite à consulter le pkgsrc guide[11] pour en connaître davantage et étancher votre soif de curiosité.

3.4 Le processus pkgsrc

Quand on installe un logiciel via pkgsrc, le processus lancé passe par quelques phases :

- fetch : cette phase consiste à récupérer l'archive qui contient les sources du logiciel que l'on souhaite installer ;

- checksum : on est jamais trop prudent, pkgsrc va vérifier l'intégrité de l'archive via un checksum basé sur 2 algorithmes : SHA1 & RMD160 ;

- extract : l'archive étant compressée, on extrait les sources (dans le répertoire work) ;

- patch : les patches sont là pour corriger les sources, par exemple en changeant l'appel d'une bibliothèque qui porterait un nom différent, … ;

- tools : c'est à ce niveau que pkgsrc va analyser les outils dont il aura besoin pour compiler les sources comme bzcat, … ;

- wrapper : le wrapper[10] va être créé afin de faire abstraction du compilateur utilisé (on peut utiliser GCC ou un autre compilateur) ;

- configure : phase classique avant compilation, l'analyse des appels système, des fichiers header, … ;

- build : la compilation proprement dite ;

- test : certains logiciels possèdent une phase de tests incluse dans leur mode de compilation. On peut citer maxima ou php5 par exemple, et donc on peut décider que ce test devienne une sécurité supplémentaire lors de la compilation via pkgsrc ;

- install : les fichiers une fois compilés seront placés au bon endroit, la base des programmes installés mise à jour.

3.4.1 Autres directives intéressantes dans le fichier mk.conf

Maintenant que vous savez utiliser pkgsrc, il convient d'aller un peu plus loin dans la configuration du fichier mk.conf :

- LOCALBASE : par défaut, si rien n'est spécifié, tous les logiciels seront installés dans /usr/pkg mais l'on peut changer cela grâce à la directive : LOCALBASE?=un_autre_repertoire ;

- WRKOBJDIR : par défaut et comme je l'ai dit ci-dessus, quand un logiciel est compilé via pkgsrc, un répertoire work est créé. On peut très bien spécifier un répertoire work pour tous les logiciels que l'on installera avec la directive : WRKOBJDIR=mon_repertoire_work ;

- DISTDIR : j'ai parlé du téléchargement des archives contenant les sources, par défaut le répertoire nommé distfiles se place dans /usr/pkgsrc/ mais avec la directive DISTDIR?=mon_autre_repertoire, on peut changer la destination par défaut. Une purge régulière de ce répertoire peut se faire via la commande make distclean qui aura donc pour conséquence d'effacer toutes les archives qui y sont présentes ;

- FETCH_USING : les habitués de GNU/Linux téléchargent en général les archives via wget mais sous NetBSD, on utilise l'outil ftp par défaut, la directive FETCH_USING?=mon_programme permettra donc de changer le programme de téléchargement par défaut ;

- SKIP_LICENCE_CHECK : vous avez vu ci-dessus que l'on a spécifié la directive ACCEPTABLE_LICENSES. Si cela vous agace de devoir spécifier systématiquement votre accord avec une licence, vous pouvez ajouter la directive SKIP_LICENCE_CHECK=yes afin d'outrepasser cela. Il est à noter que la construction d'un logiciel s'arrête si l'accord avec la licence n'a pas été spécifié. La totalité des licences des logiciels contenus dans l'arbre pkgsrc sont disponibles dans ce répertoire : /usr/pkgsrc/licenses/ ;

- PASSIVE_FETCH : cette directive permet de spécifier que l'on utilisera le mode passif lors de l'utilisation de la commande ftp pour récupérer les archives.

J'arrête ici la liste des directives, je ne vous ai cité que celles qui me paraissaient pertinentes pour débuter avec pkgsrc. Si vous en voulez plus, je vous invite à consulter le fichier suivant : /usr/pkgsrc/mk/defaults/mk.conf qui liste une grande quantité d'autres directives. La documentation du pkgsrc guide[9] vous donnera également des explications plus approfondies.

3.4.2 Mets-moi tout ça au chaud

Après s'être donné la peine de compiler un certain nombre de logiciels, on peut très bien garder tout ça au chaud dans un coin, soit parce qu'on va installer une nouvelle machine avec les mêmes logiciels, en cas de crash d'un disque dur ou pour toute autre bonne raison. Nous allons utiliser pour ça l'utilitaire pkg_tarup. Si vous voulez créer le binaire pour un seul package, la commande sera très simple : pkg_tarup mon_logiciel et le binaire sera généré à l'emplacement où vous vous trouvez. Si vous voulez sauvegarder l'ensemble de vos logiciels[12] :

La commande pkg_info -e '*' retourne le nom du logiciel sans son descriptif. Le répertoire mypackages contient maintenant tous les logiciels installés via pkgsrc sous forme binaire.

3.4.3 Effacer un logiciel

Comme il est simple d'installer un logiciel, il est encore plus enfantin de le supprimer. La commande pkg_delete est là pour ça. Si l'on revient sur les logiciels que j'ai installés précédemment, cette simple commande supprimera pkgfind :

Une des particularités des systèmes BSD est de séparer la couche système de la couche applicative. En effet, lors du précédent article, on a pu se rendre compte que le système fonctionnait parfaitement de base et que nous avions installé le logiciel sudo que par la suite. Dans cet article, nous avons posé l'arbre pkgsrc puis compilé un logiciel. Nous pourrions très bien envisager, pour une raison ou une autre, de supprimer tout ce qui a attrait aux logiciels sur notre système, sans avoir aucun effet sur le système en lui-même (à part bien sûr de ne plus disposer des logiciels installés) :

et voilà, l'OS à la serviette orange se retrouve nu comme au premier jour. C'est un peu radical, mais on va voir dans le chapitre suivant qu'un manque de prudence pourrait nous conduire à cela.

3.5 Mettre à jour les logiciels installés

Le framework pkgsrc est très bien pensé, mais la mise à jour de logiciel peut s'avérer périlleuse. En effet, mettre à jour un logiciel ne pose pas de problème, mais un logiciel dépend très fréquemment d'une multitude d'autres, et c'est là que les choses se corsent. On pourrait imaginer cela sous forme d'une chaîne, si un maillon défaille, la chaîne devient inutilisable. Sous Freebsd, par exemple, chaque port mis à jour à l'aide de portupgrade est d'abord sauvegardé pour être rollbacké si quelque chose se passait mal. Sous NetBSD, ce ne sera pas le cas, le logiciel mis à jour sera d'abord effacé (ainsi que ses dépendances) avant que la compilation de la nouvelle version se lance.

3.5.1 pkg_chk

Cet outil pourrait être comparé à portversion. Il s'agit de comparer la version d'un logiciel installé à celle présente dans l'arbre pkgsrc :

Le flag -u est invoqué pour l’upgrade et -q pour ne lister que ce qui va être fait, sans lancer aucune opération. Nous connaissons ainsi les logiciels à mettre à jour.

3.5.2 Make update

La target update va donc lancer le processus de mise à jour du logiciel choisi et de toutes ses dépendances. Il commencera par une première phase qui consistera à désinstaller le logiciel et sa suite. Nous revoilà sur la problématique de tout à l'heure, l'incident de compilation qui rendrait le tout bancal.

3.5.3 Make replace

La target replace peut être un autre choix pour la mise à jour d'un logiciel. Cette commande ne remplacera que le logiciel en question, sans se soucier de ses dépendances. Retour à la case départ, l'accident de compilation nous guette.

3.5.4 pkg_comp

Bon, me direz-vous, mais que faire alors ? Il existe une solution parmi d’autres qui va permettre de construire tranquillement nos mises à jour sous forme de paquets binaires dans un environnement chrooté (vous voyez le lien avec pkgin et les multi repositories ?). Il s'agit de l'utilitaire pkg_comp (son installation via pkgsrc ne devrait pas vous poser de problème si vous avez bien suivi le début de l'article ;) ).

- création du template de pkg_comp : il s'agit d'un fichier qui reprend quelques directives de mk.conf et en comporte d'autres, comme l'emplacement des sets binaires utilisés lors de l'installation de l'OS :

Le fichier se trouve donc dans ${home}/pkg_comp/default.conf (ici $HOME=root) et nous allons l'éditer afin de changer la directive DISTRIBDIR par :

Le répertoire binary contiendra un répertoire sets avec les sets cités dans default.conf.

- création de l'environnement : # pkg_comp makeroot

- entrée dans le chroot :

Afin de ne plus avoir le warning : /usr/pkgsrc/distfiles/pkg-vulnerabilities not found, il suffit de télécharger le fichier pkg-vulnerabilities et de le placer dans /usr/pkgsrc/distfiles :

- génération de la liste des logiciels installés : je vous parlais précédemment de l'utilitaire pkg_chk. Il va également jouer un rôle ici, en générant la liste des logiciels installés dont pkg_comp va se servir pour compiler les mises à jour. Pour générer ce fichier, nous lancerons la commande :

Un fichier nommé pkgchk.conf sera généré dans /usr/pkgsrc/ et contiendra la catégorie du logiciel ainsi que son nom, par exemple : lang/perl5 pour perl 5 qui se trouve dans la catégorie lang (pour language).

- compilation : nous y voilà, on lance la commande qui va construire tout ce petit monde et qui déposera le tout dans le répertoire /usr/pkgsrc/packages/All (pour changer cette destination, il suffit de changer la directive : REAL_PACKAGES=”/usr/pkgsrc/packages” dans le fichier template (default.conf) de pkg_comp) :

Si vous avez beaucoup de logiciels à mettre à jour, vous pouvez tranquillement lire le GLMF du mois (si ce n'est déjà fait) :).

- mise à jour des logiciels : prudence étant mère de sûreté, il vaut mieux s'assurer que la liste des binaires fraîchement compilés est la même que celle contenue dans pkgchk.conf afin d'éviter de rendre notre système bancal. Après cette petite vérification, on lance la commande :

Le flag b pour forcer l'usage des binaires et u et a pour lancer les mises à jour (un man pkg_chk(8) vous donnera plus d'informations sur l'usage et la signification des flags de pkg_chk). Notre système est à jour, pas de mauvaise surprise, tout va bien.

A ce niveau, nous aurions très bien pu lancer pkgin pour qu'il fasse le même travail.

Conclusion

Voilà, déjà la fin de l'article. L'OS à la serviette orange est loin d'avoir livré tous ses secrets. Mais vous pouvez maintenant utiliser l'OS et sa myriade de logiciels disponibles (un peu plus de 10 000). Le site http://pkgsrc.se vous permettra de faire des recherches sur l'arbre, mais également de voir le contenu des logiciels via le Web.

N'hésitez surtout pas à vous lancer dans la création de nouveaux logiciels dans la branche WIP. Plus il y a de contributeurs, plus le nombre de logiciels disponibles va croître. pkgsrc dispose d'un channel officiel que vous pouvez rejoindre sur #pkgsrc@freenode, ou lire/poster sur les mailing lists dédiées à pkgsrc[14]. A bientôt pour le prochain épisode !

Références

[1] http://www.tsgk.net/cowboyz/linux.html

[2] http://imil.net/

[3] http://imil.net/pkgin/

[4] http://www.netbsd.org/docs/software/packages.html

[5] http://www.dragonflybsd.org

[6] http://www.dracolinux.org/

[7] http://leaf.dragonflybsd.org/mailarchive/users/2009-09/msg00053.html

[8] http://pkgsrc-wip.sourceforge.net/

[9] http://www.netbsd.org/docs/pkgsrc/configuring.html

[10] http://www.netbsd.org/gallery/presentations/joerg/eurobsdcon2009/wrapper.html

[11] http://www.netbsd.org/docs/pkgsrc/build.html#build.helpful-targets

[12] http://wiki.netbsd.se/How_to_save_your_packages

[13] « Zone0 : le serveur presque parfait », GNU/Linux Magazine France hors-série n°36, ou http://www.unixgarden.com/index.php/administration-systeme/zone0-le-serveur-presque-parfait

[14] http://mail-index.netbsd.org/index.html