C’est bien beau d’avoir fait un beau morceau de codaz, mais faut encore le distribuer. Et là, c’est le drame. Le _gens_ veut un clicka-truc, un tar.gz à compiler ça lui parle pas au gens. D’ailleurs, il ne sait pas compiler, faut lui mâcher le boulot. Ça, c’est la vision *aigr* du packaging. La vision happy-bisounours, c’est qu’il y a un projet qui te tient à cœur, t’as envie d’aider les gentils développeurs à répandre la bonne parole (leur code, si tu suis bien mon raisonnement) et donc tu aimerais le mettre facilement à disposition des gens qui utilisent ton *BSD du bien. C’est là que l’infrastructure des ports BSD entre en jeu. Et attention, elle va vous sortir le grand jeu. Alors vous savez déjà qu’il y a 3 "flavors" principales de BSD, donc nous sommes allés chercher pour vous les spécialistes en la matière pour chacune des flavors. Ou, du moins, on a essayé. Malheureusement pour les amateurs de la boule rouge, notre gourou préféré est tombé dans une embuscade (du Vim dans un fichier de 16 Go, ça vous tente ?)... Alors seuls Net et Open auront l’honneur de vous dévoiler leurs secrets intimes sous la houlette de talentueux magiciens. Non, ils n’ont pas appris sur le tas la semaine dernière en bricolant un bridge sur une Founera. Jamais, nulle part, avec personne.

Généralités

Tout se passe dans une arborescence dans le système de fichiers : /usr/ports pour Free et Open et /usr/pkgsrc pour Net. Dans les grandes lignes, un port est composé d’un BSD Makefile et de 2-3 trucs décrivant le paquet et les sources. Pour une description plus détaillée, se reporter à l’excellent article (quoiqu’un peu outdated) de M. Bedis dans le hors-série acte I, que tu peux commander ici (http://ed-diamond.com/ugproduit.php?produit=462) si tu ne l’as pas encore. Grosso modo, pour installer un port via les sources, on fait cd /usr/{ports,pkgsrc}/<category>/<port> && make install clean. Bien évidemment, on peut utiliser les packages binaires mis à disposition dans les dépôts officiels, mais c’est un peu hors propos ici vu qu’on veut créer un port. De toute façon, un package binaire n’est jamais que le résultat de la compilation d’un port via make package.

Port OpenBSD

AuverViou

Rentrons tout de suite dans le vif du sujet et décortiquons un port existant (j’ai volontairement strippé les répertoires CVS qu’on retrouve dans un ports-tree) : Comme on peut le voir ci-dessus, un port OpenBSD complet se compose d’un BSD Makefile, d’un fichier distinfo contenant différentes informations sur l’archive des sources du logiciel porté (taille, sommes md5/sha...), d’éventuels patches, d’un fichier DESCR décrivant en quelques lignes le logiciel, et enfin d’un fichier PLIST listant les fichiers installés par le logiciel. Regardons tout d’abord comment se passe l’installation du logiciel, pour avoir la succession des différentes étapes : Quelques commentaires sur les différentes étapes...

• Le rapatriement des sources. C’est le résultat de make fetch, qui va vérifier si les sources du logiciel n’existent pas déjà dans /usr/ports/distfiles et, le cas échéant, les y téléchargera à partir du ${MASTER_SITES} (que nous verrons plus tard).
• La vérification de l’intégrité des sources, par make checksum. On compare les sommes de contrôle contenues dans le fichier distinfo avec celles obtenues avec l’archive des sources présente dans /usr/ports/distfiles.
• La vérification des dépendances, par make depends. Va éventuellement installer les dépendances manquantes du logiciel, que ce soient des dépendances à l’exécution (run-depends), des dépendances à la compilation (build-depends) ou des dépendances sur des bibliothèques partagées (lib-depends). Il faut noter que les dépendances à l’exécution seront installées juste avant l’installation de notre port. Une dépendance à la compilation sera en général un compilateur, un script particulier (GNU make, libtool...), utilisé uniquement pendant la construction du package, alors qu’une dépendance sur une bibliothèque sera requise par le logiciel lui-même (p. ex. Gnome dépendra des bibliothèques gtk2).
• La décompression des sources, c’est l’équivalent de make extract. L’infrastructure des ports reconnaît la plupart des types d’archives (.tar.gz, bz2, .Z...). À partir de maintenant, tout va se passer dans ${WRKDIR}, qui est un répertoire de travail situé dans le répertoire du port et nommé w-${PKGNAME} où PKGNAME est le nom complet de notre logiciel. Les sources sont extraites dans un sous-répertoire de ${WRKDIR} nommé ${WRKDIST}. Dans l’exemple pour unrar, les sources seront donc dans /usr/ports/archivers/unrar/w-unrar-3.68p0/unrar.
• Le patching de ces sources via make patch, avec les éventuels diffs trouvés dans le répertoire patches/. Ici, les patches sont nécessaires pour adapter les sources originales (vanilla) du logiciel et le faire fonctionner sur OpenBSD. Généralement, ce sont des patches de sécurité, des modifications de Makefile, des #define à gauche à droite... Dans un monde idéal, ces patches n’auraient pas lieu d’exister, et toutes les modifs seraient remontées à l’auteur du logiciel qui les aurait appliquées après vérification. Nous verrons que c’est rarement le cas, et que plein de gens codent rarement dans une optique code-portable-à-100%.
• La configuration des sources, faite par make configure. Ici, deux grandes écoles, les logiciels qui utilisent les GNU autotools et les autres. C’est à cette étape que les Makefile des sources seront créés par ./configure si l’on utilise les autotools. Si l’infrastructure des ports trouve un fichier scripts/configure, elle l’exécutera en premier.
• La compilation des sources, équivalent de make build. Ici, rien de bien sorcier, on va dans le répertoire de travail, et on appelle ${MAKE_PROGRAM}, qui sera soit BSD-make, soit GNU-make en fonction de USE_GMAKE. On y reviendra plus tard.
• La pseudo-installation, résultant de make fake. C’est une petite spécificité de l’infrastructure des ports OpenBSD, une pseudo-arborescence du système est créée par mtree(8) dans un sous-répertoire du répertoire de travail nommé ${WRKINST} (fake-${MACHTYPE}), en utilisant le squelette ${PORTSDIR}/infrastructure/db/fake.mtree. On va ensuite faire une vraie installation du logiciel dans cette pseudo-arborescence.
• La construction du package binaire proprement dit, par make package. Cette étape va créer le package foo-version.tgz à partir de la pseudo-arborescence, en y ajoutant un fichier +CONTENTS contenant diverses informations sur le package (la packing-list). Le fichier de description du logiciel pkg/DESCR est aussi ajouté au package, qui est créé dans ${PACKAGES_REPOSITORY} (généralement /usr/ports/packages). Plus précisément, le package réel sera dans ${PACKAGES_REPOSITORY}/${MACHTYPE}/all, et des liens symboliques seront créés dans des répertoires cdrom/ et ftp/ si la licence du logiciel permet sa libre redistribution.
• Enfin, on arrive à l’installation du logiciel sur le système, via make install. Cette cible va tout simplement appeler pkg_add(1) avec le package que nous venons de créer. Cette commande va tout d’abord vérifier qu’il n’est pas déjà installé, vérifier qu’il ne rentre pas en conflit avec d’autres packages, re-vérifier que les dépendances (d’exécution ET de bibliothèques) sont bien satisfaites, le décompresser effectivement dans /usr/local (aussi connu sous le petit nom de ${LOCALBASE}), et enregistrer les informations connexes au package dans /var/db/pkg/${FULLPKGNAME} comme le contenu du package, sa description. Enfin, on enregistre les informations de dépendances directement dans les fichiers /var/db/pkg/’PACKAGE_DONT_JE_DEPEND’/+REQUIRED_BY.
• Et puis, vu qu’on n’est pas des gros gorets *hruuuiiikk*, on va faire un peu de nettoyage avec make clean. Par défaut, ça supprimera le répertoire de travail, mais on peut aussi supprimer le package créé via make clean=package, ainsi que les sources d’origine avec make clean=dist.

Voilà, on a fait le tour dans les grandes lignes de l’infrastructure de build d’un port OpenBSD. Sans plus attendre, passons à la pratique, car je sens que vous piaffez d’impatience... Pour l’exemple, nous allons écrire un port pour un package fournissant une bibliothèque partagée et un port pour un logiciel qui a besoin de cette bibliothèque. Attention, c’est un vrai exemple en direct-live et tout, rien dans les manches, rien dans le chapeau !!

Défrichons le terrain

<mode vie_réelle=’ON’> Bon, disons que j’ai installé un OpenBSD en desktop-convi-clicka, avec un <prosel> joli Xfce4.4 </prosel> grâce aux ports d’un certain monsieur Maniak. Et imaginons, soyons fous, que j’aie envie de faire un truc bête de gens, comme gérer mes comptes en banque à moi, quelle idée sottte-et-grenue. Un petit coup de googlage, j’apprends que sur les os du bien il existe GnuCash, KmyMoney, et Grisbi. Bon, direct j’élimine GnuCash, un peu trop usine à gaz à mon goût, y’a pas encore la version gtk2 dans les ports, et y’a des dépendances de malade genre tout GNOME, Audiofile et j’en passe... Vu que je connais déjà Grisbi sous minusque (oui, je triche), et que je n’ai généralement pas de libs Qt/KDE installées sur mon système, allez hop, Grisbi est le vainqueur de mon comparatif à-la-louche-totalement-impartial. Houbahop, direction /usr/ports. mrrbllbmmrm... bon. Donc va falloir s’y coller. <mode vie_réelle=’OFF’> Hepaaa, vous avez vu comment j’ai bien amené mon exemple ? La classe américaine, j’vous dis. Histoire de se faire un petit espace-à-soi-douillet dans le ports-tree, on va faire ce que nous conseille la doc : se créer un /usr/ports/mystuff avec le chown moi:moi kivabien. Histoire de ne pas être trop embêté par des histoires de droits, un pti chmod -R +gw /usr/ports/{distfiles,packages} permettra d’écrire aux bons endroits (si vous faites partie du groupe wheel évidemment) ; et enfin, un petit echo SUDO=/usr/bin/sudo >> /etc/mk.conf dira au ports-tree d’utiliser sudo quand il le faudra (principalement pour l’installation). Commençons par le commencement, faire marcher le make fetch extract. Un coup d’œil sur la checklist, et sur un autre port pris au hasard et on commence avec ça dans son /usr/ports/mystuff/grisbi/Makefile : C’est vraiment l’extra-minimum. COMMENT est une courte description de l’appli, MASTER_SITES et DISTNAME sont utilisés pour savoir où aller chercher les sources (j’ai précisé EXTRACT_SUFX car, par défaut, l’infrastructure des ports s’attend à un .tar.gz, mais les sources de Grisbi sont disponibles uniquement sous forme de .tar.bz2.) Bien renseigner ces champs, l’infrastructure des ports appellera ${FETCH_CMD} (par défaut ftp(1)) avec ${MASTER_SITES}${DISTNAME}${EXTRACT_SUFX} en argument. NE PAS oublier le / à la fin de MASTER_SITES !! Le champ CATEGORY est obligatoire aussi, il sert à savoir où va aller notre port. HOMEPAGE et MAINTAINER ne sont pas obligatoires pour le moment, mais hautement conseillés. Enfin, les PERMIT_* sont obligatoires, pour renseigner les conditions de redistribution des sources et des binaires. Ici, Grisbi est sous licence GPL, donc pas de problèmes. Et finalement, .include <bsd.port.mk> va charger le reste de l’infrastructure des ports. Allez, hop, soyons fous, on teste : Erm, oui, évidemment, on a oublié un petit détail, le fichier distinfo. Un petit coup de make makesum, et hop, c’est réparé. Et voilà, il m’a créé le répertoire de travail, et décompressé les sources dans w-grisbi-0.5.9/grisbi-0.5.9. Maintenant, il faut préciser comment configurer ces sources. Grisbi utilisant les GNU autotools, il faut en informer l’infrastructure des ports. Tant qu’on y est, vu que c’est un logiciel clicka-convi, on va dire qu’on utilise X. Hop, un coup de make configure, et les ennuis s’approchent à grands pas. Globalement, ça se passe bien, sauf pour ça : Mh, il lui manque une bibliothèque, qui en plus n’existe pas dans le ports-tree. Elle n’est pas _requise_, mais elle permet à Grisbi de supporter le format OFX, qui est un format d’échange ouvert standardisé, beaucoup plus générique que le QIF, format de Quicken (que Grisbi sait lire aussi.) Et puis, ho-comme-de-par-masard, je voulais vous montrer comment écrire un port pour une bibliothèque, ça tombe bien. (*rires enregistrés*). Donc, pour l’instant, on laisse Grisbi de coté, et on s’attaque à libofx dans /usr/ports/mystuff/libofx.

Ça se complique, y'a des branches récalcitrantes

Comme pour le précédent, un Makefile de base, puis make configure (qui appellera tout seul comme un grand les cibles fetch et extract) : Ici, petite spécificité, on a mis USE_LIBTOOL pour dire "on va créer une bibliothèque partagée avec GNU libtool". Hop, make configure, et là c’est le drame. Bon, ça veut dire quoi tout ça... Il veut OpenSP, qui est un parseur SGML, et qui, évidemment, n’est pas dans le ports-tree. Non, on ne va pas écrire un port pour OpenSP (j’ai essayé, il a pas voulu). Alors rusons un peu, il existe déjà un parseur SGML dans le ports-tree dans textproc/sp. On va voir si y’a pas moyen d’y mettre un p’tit coup de lime par-là, un p’tit coup de rabot par-ci, et de le faire rentrer au chausse-pied. En fait, on a du bol, ça marche, faut juste tweaker un bail le script configure de libofx pour qu’il teste la présence de -lsp au lieu de -losp. Hop, comme par magie, il nous a fait un patch tout beau !! On tweake un peu le Makefile pour passer les bonnes options à configure et corriger 2-3 trucs : Et hop, on peut faire make clean patch configure build ou, tout court, make build. Ça compile. Yallah @#!@#!. Maintenant, passons au packaging proprement dit. Pour ça, il faut renseigner pkg/DESCR avec 3-4 lignes expliquant le pourquoi du comment du biniou, et faire un petit coup de make update-plist pour qu’il crée la pré-packing-list du package. D’ailleurs : Normal, on a oublié de dire dans notre Makefile que ce port créait une bibliothèque partagée... USE_LIBTOOL = Yes ça suffit pas, on y ajoute ici SHARED_LIBS = ofx 3.1. Maintenant, on passe à l’étape "déclaration des papiers à la frontière", aka make clean lib-depends-check. Normal, un petit warning sur la fin, je n’ai déclaré aucune dépendance comme un gros sagouin. Même pas de LIB_DEPENDS. Théo, Deanna, Miod et Marc risquent de venir me lyncher en personne (*kh0f*), donc je corrige ça fissa : Et hop youp-la-boom, on peut faire make install, et avoir la joie de faire un pkg_info libofx et de voir son nom dans la ligne Maintainer. Enfin, c’est aussi hautement conseillé de faire un certain nombre de cycles make clean && make update-patches && make lib-depends-check pour bien triple-vérifier que y’a plus de trucs qui dépassent. Ceintures, bretelles et combinaison de décontamination sont les 3 mamelles du pantalon bien attaché. Relisez 172 fois la doc aussi.

Encore un petit coup de tondeuse

Revenons à nos moutons, maintenant que nous avons réglé le cas de la branche qui dépassait. Hophop, cd ../grisbi. On a installé textproc/libofx, tentons maintenant de le faire détecter par le ./configure de Grisbi. Ici, je triche un peu pour le forcer à trouver libofx, et pour des problèmes de résolution de symboles je rajoute -lsp, car la bibliothèque fournie par les ports étant statique, la résolution ne peut se faire toute seule... C’est en tâtonnant qu’on devient *khof* non rien. Hopla, du coup, make clean build passe comme une lettre à la poste. On remplit pkg/DESCR, on génère la packing-list... Et on passe au nettoyage, avec un coup de make lib-depends-check... Vu qu’on n’a rien renseigné comme dépendances, il se plaint. Évidemment. Jamais content. Il en manque un peu, on va faire ça en deux fois... On rajoute la ligne WANTLIB à notre Makefile, et on reteste un make clean lib-depends-check. C’est déjà beaucoup mieux, il résout les dépendances vers les bibliothèques du basesystem. Au passage, j’ai rajouté MODULES = devel/gettext, car le logiciel se base sur gettext pour la gestion des langues... Le mot-clé MODULES sert à "activer" un des modules de l’infrastructure des ports situés dans /usr/ports/infrastructure/mk. Bon, par contre, tous ces NOT REACHABLE, ça jure... Ce sont les dépendances envers des bibliothèques installées par le ports-tree que l’on a "oublié" *khof*. Allez hop, on cherche un peu dans son arbre, on bricole, on scotche, on lime, on meule... Et on nettoie ça. Après quelques incantations vaudou et en lisant soigneusement bsd.port.mk(5), j’ai fini par trouver library-specs(7) qui m’a expliqué la syntaxe d’une déclaration de dépendance. Je suis sûr que vous allez vous poser la question hééé pourquoi y’a truc dans LIB_DEPENDS et machin dans WANTLIB ?? Ils sont cons chez OpenBSD, ça fait double emploi !!. Je me la suis posée aussi. En fait, LIB_DEPENDS est plutôt pensé pour les dépendances "directes", ici libofx/gtk2/libxml2, et WANTLIB pour les dépendances "indirectes", aka. les dépendances des dépendances... Pas bête, non ? Hop, on reteste... Il ne dit rien... Victoire !!!! Bon évidemment, j’avais toutes les dépendances nécessaires installées, mais vous avez compris le principe. Reste plus qu’à faire make install, relire encore 172 fois la doc, faire un cycle de make clean && make lib-depends-check && make install... Faut pas se louper, sinon on est grillé à vie après.

/* FIXME: TODO !! */

Bon, évidemment, tout ceci était mon interprétation personnelle de la doc, la doc est belle, espie@ est grand, la doc fait revenir l’être aimé, la doc rend riche, la doc rajeunit ton bide, il _faut_ lire la doc. Ça va, j’insiste pas trop ? Parmi les choses qu’il resterait à aborder, il y a les FLAVORS, les MULTI-PACKAGES, la création d’un port n’utilisant pas les autotools, l’installation d’un daemon, etc. Pour des infos sur tout ça, il faudra écouter Radio Trouville FM –clin d’œil entendu–.

Real men don't do backup, they upload their stuff on the net and let others mirror it

Voilà, j’ai fait le tour de ce que je connaissais/maîtrisais, à vous la joie de l’écriture des ports OpenBSD... Une fois que votre port est prêt, reste plus qu’à en faire profiter la communauté en envoyant une annonce sur ports@openbsd.org avec un .tar.gz de votre port complet, et surtout appliquer les éventuelles corrections qui seraient remontées par des testeurs (au passage, merci à Antoine Jacoutot pour avoir jeté un œil à mes ports, les avoir nettoyés ET commités, et enfin avoir bien voulu répondre à mes questions. Comme quoi, chez Open, ils mangent pas les petits n’enfants). Communiquez aussi avec les auteurs du logiciel, remontez-leur d’éventuels bugs qui seraient ressortis de votre étape de porting, bref, soyez actif, mettez à jour votre port pour les nouvelles versions, etc. !! Si vous persévérez, peut-être qu’un jour, votre petit bout de contribution infime trouvera aussi son chemin dans le ports-tree officiel !

–gaston–

Linqses

• man (5) bsd.port.mk http://www.openbsd.org/cgi-bin/man.cgi?query=bsd.port.mk
• man (7) ports http://www.openbsd.org/cgi-bin/man.cgi?query=ports
• Écrire un port http://www.openbsd.org/fr/porting.html
• Tester un port http://www.openbsd.org/fr/porttest.html
• Checklist http://www.openbsd.org/fr/checklist.html
• Archive de ports@openbsd.org http://marc.info/?l=openbsd-ports
• Le port de libofx http://ports.openbsd.nu/devel/libofx
• Le port de grisbi http://ports.openbsd.nu/productivity/grisbi

Pkgsrc NetBSD

Introduction

Un bon exemple vaut mieux qu’un long discours ! Je vais donc vous décrire comment porter un logiciel dans pkgsrc en procédant par l’exemple. Tout le monde connaît l’excellent vlock, qui permet de locker un terminal. Il n’est pas présent dans pkgsrc, nous allons donc le porter !

Construction du nid

C’est la première étape ! Vous allez tout d’abord installer url2pkg : Cet outil va nous permettre de construire la base de notre package pkgsrc. On va tout d’abord se créer un petit nid, qui accueillera notre jeune pousse. Maintenant que le nid est prêt, on va y mettre les meubles : NOTE Il est recommandé d’utiliser le repository des sources officielles. Seulement, pour vlock, y’en a pas, alors système D... Voyons un peu nos meubles : Premier point important : nous avons là sous nos yeux ébahis, le minimum requis pour créer un package dans pkgsrc. C’est-à-dire :

• un fichier qui décrit le package : DESCR ;
• un Makefile pour construire le package ;
• une liste des fichiers installés par le package dans PLIST ;
• un fichier contenant les hashs des fichiers sources : distinfo ;
• un répertoire work où l’on va compiler les sources.

Tant qu’on y est, pensez à éditer le Makefile et à changer les directives en MAJUSCULES :

Préparer la venue du poussin

Bon, ben notre petiot là, il doit bien se compiler sur d’autres OS, mais il risque de ne pas se compiler sur notre serviette orange (NetBSD pour ceux qui n’ont pas suivi)... On va donc se préparer quelques petits patches à appliquer. Pour cela, décompressez les sources dans un répertoire dans votre $HOME, puis tentez un premier make : Tout d’abord, créez une copie de vlock.c, qui nous permettra de créer le patch. sys/vt.h et sys/kd.h sont spécifiques au pingouin. Pour envelopper notre poussin dans une belle serviette orange, on va supprimer ces includes dans le source et les remplacer par un include de dev/wscons/wsdisplay_usl_io.h. Bon, vlock.c passe maintenant, appliquons la même séquence à signals.c ! Et re-make : Bon, encore ce bloody sys/vt.h... On applique la même procédure là encore ! Et on repart : Ah, enfin, ça change un peu : sauvegardons input.c. security/pam_misc.h sous Linux s’appelle security/openpam.h sous NetBSD... Tant qu’on y est, à la ligne 67, remplacez la fonction misc_conv par openpam_ttyconv. On re-make (c’est chiant, hein ? Ben non, c’est kiffant !) Bon, ben voilà, le code source compile. Il y a juste un petit souci de liaison avec les libs partagées. Pour ça, sauvegardez le fichier courant et remplacez par ce contenu : et un dernier make pour vérifier que tout se passe bien : \o/ Ça compile !!!!

La chambre du petit

Bon, on va mettre à jour notre package. Dans le répertoire du package, créez un répertoire patches. Depuis le répertoire où l’on a travaillé notre bébé, préparez le papier peint : Et on fait les finitions. Exécutez cette commande dans le répertoire du package : Ca va permettre de mettre à jour le fichier distinfo avec les hash des patches :

Rentrée des classes

C’est pas le tout de faire des patches, encore faut-il que notre package s’installe proprement. On va modifier légèrement le Makefile généré par url2pkg en rajoutant la phase d’installation : Maintenant, on teste l’installation. Exécuter directement dans le répertoire du package : Le premier jour d’école du petit s’est bien déroulé. Il est dans la classe, avec ses potes. Bon, si on utilise pkg_delete pour supprimer notre vlock, les fichiers ne seront pas supprimés. Il va falloir améliorer le Makefile.

Les premiers cours

Bon, c’est bien, on a vu par l’exemple comment créer un package dans pkgsrc. Un exemple sans la théorie, c’est comme un bon fromage sans le vin. Il y a un manque ! Je vais donc m’efforcer de combler ce manque ici.

Présentation de pkgsrc

Pour utiliser un logiciel sur un Unix, il faut récupérer les sources, installer des dépendances si besoin, le compiler, etc. Ce n’est pas une mince affaire ! Sous NetBSD, toutes ces opérations sont gérées dans pkgsrc. pkgsrc n’est autre qu’un arbre dans lequel on retrouve nos logiciels classés en catégories. Pour chacun de ces logiciels, il existe des directives de compilation, des patches, etc. Chaque logiciel dans l’arborescence de pkgsrc est appelé "package". On peut bien sûr s’affranchir de la compilation en utilisant les versions binaires des packages.

Description d'un package

Un package est donc un logiciel "porté" dans NetBSD. On a vu qu’il devait permettre à ce logiciel de s’installer et, pour cela, il doit répondre à certaines questions :

• Mais quel est donc ce logiciel porté ? -> un fichier DESCR contient un petit blabla sur le logiciel.
• Comment récupérer les sources, compiler et gérer les dépendances ? -> un fichier Makefile (et fait bien d’autres choses encore).
• Un logiciel, c’est bien, mais quels sont les fichiers installés ? -> tout est dans le fichier PLIST
• HAHA, facile de récupérer les sources, mais qui me dit qu’elles n’ont pas été corrompues ? -> le fichier distinfo contient les hashes des sources et des patches (pour plus de garantie !!!).
• Ben et si le logiciel est écrit pour un autre OS du bien, mais qu’il ne compile pas ? -> le répertoire patches est là pour ça !

Ces fichiers peuvent être complétés par ceux ci-dessous, qui sont OPTIONNELS :

• INSTALL : appelé par pkg_add à l’installation du package ;
• DEINSTALL : appelé par pkg_delete à la désinstallation du package ;
• MESSAGE : le contenu de ce fichier sera affiché après l’installation du package ;
• README : purement informatif ;
• TODO : idem README.

Vous pouvez utiliser pkgtools/pkglint pour être sûr que votre package est bien conforme au cahier des charges de pkgsrc. L’exemple de vlock étudié plus tôt comporte quelques non-conformités (fichiers PLIST et DESCR vides, notamment), mais comme vous l’avez vu, ça ne l’empêche pas de se compiler et de s’installer. Bref, pkglint est un plus pour rendre un travail propre et soigné !

Le Makefile

C’est le fichier le plus important du package. Building, installation and creation of a binary package are all controlled by the package’s Makefile. The Makefile describes various things about a package, for example from where to get it, how to configure, build, and install it. C’est grâce à ce fichier que pkgsrc saura comment compiler, installer et créer un package binaire. Le Makefile décrit divers paramètres du package. Voici les éléments que doit obligatoirement contenir ce fichier :

• DISTNAME : c’est le basename du package qui sera téléchargé sur le site du package.
• PKGNAME : c’est le nom du package utilisé dans pkgsrc.

A fournir uniquement si DISTNAME n’est pas un nom acceptable dans pkgsrc (doublon ou autre...).

• CATEGORIES : liste de catégories auxquelles le package correspond.
• MASTER_SITES : site où récupérer les sources.
• MAINTAINER : qui gère le package dans pkgsrc ?
• HOMEPAGE : site web originel.
• COMMENT : une ligne de commentaire qui décrit brièvement le package.
• PATCHFILES : patches additionnels à récupérer sur PATCH_SITES.
• PATCH_SITES : où chercher les PATCHFILES s’ils ne sont pas trouvés localement.

Mais on peut aussi avoir besoin de choses comme ça :

• CONFLICTS : liste de packages avec lesquels notre package peut entrer en conflit ;
• GNU_CONFIGURE : est-ce que ce package utilise le configure mode GNU ?
• CONFIGURE_ARGS : arguments à passer lors du configure ;
• EXTRACT_SUFX : va permettre de savoir comment décompresser l’archive ;-p
• MAKE_FILE : permet d’indiquer un autre nom que le Makefile classique... ;
• DEPENDS : package requis pour l’installation de notre package.

distinfo

Ce fichier contient les checksums de tous les fichiers nécessaires à la construction du package : fichiers des sources et des patches. On peut regénérer ce fichier avec la commande :

Les patches

Comme nous l’avons vu précédemment, la plupart des packages ne compilent pas, une fois sortis du four ! Afin de pouvoir utiliser lesdits packages sur NetBSD, il faudra les compiler en utilisant les fichiers dans le répertoire patches/. Dans ce répertoire, les noms de fichiers doivent être de la forme patch-XX où X est une lettre minuscule. Chaque patch doit être au format diff -bu et ne s’appliquer qu’à un seul fichier source. Comment générer les patches simplement ? Placez-vous dans le répertoire de votre package dans l’arbre pkgsrc. Vous devez avoir vos sources dans un répertoire work. Comme nous l’avons fait pour tout notre exemple, faire une copie de chaque fichier original que vous modifierez lors du portage du package sur NetBSD. Pour gagner du temps, on peut utiliser pkgvi pour modifier le fichier : il va lui-même créer le .orig et ouvrir un beau vi sur le fichier à éditer, puis va créer le patch dans work/.newpatches. Pour profiter de la magie de pkgvi, installez le package pkgtools/pkgdiff. (Merci à Gui²) Maintenant, il suffit d’exécuter la commande suivante : C’est automagically. Les patches sont générés automatiquement, et placés dans le répertoire adéquat. Ne pas oublier un petit make distinfo.

Description

Un fichier DESCR doit aussi être renseigné. Il est là pour décrire le logiciel de manière détaillée.

PLIST

Ce fichier contient la liste de tous les binaires, fichiers de configuration, manuels, etc. installés par notre package. Encore une fois, on peut le générer facilement : Pour générer ce fichier, redirigez la sortie du make print-PLIST vers PLIST ! Il y aurait beaucoup à dire sur PLIST. Pour plus d’info, lisez ceci : http://www.netbsd.org/Documentation/pkgsrc/plist.html

Fichiers optionnels

Notre package peut contenir quelques fichiers optionnels pour réaliser différentes tâches :

• INSTALL : script shell exécuté à l’installation du package (peut servir pour faire un peu de configuration post-installation).
• DEINSTALL : script exécuté avant et après que les fichiers soient supprimés. Utile pour supprimer d’éventuels fichiers qui n’ont pas été installés par le package, mais qui lui sont utiles.
• MESSAGE : le contenu de ce fichier est affiché une fois que le package est installé. Il permet de donner quelques dernières informations à l’utilisateur.

Mais il est où le paquet ????

La dernière étape, une fois que le logiciel porté compile et s’installe proprement, c’est de créer le package. Pour ça, simplement : Maintenant, on peut installer le package binaire grâce à pkg_add. À partir de là, vous savez comment faire...

Liens

Quelques exemples de Makefile : http://imil.net/NetBSD/gcc-pkg-Makefile" target="_blank">http://imil.net/NetBSD/Makefile , http://imil.net/NetBSD/gcc-pkg-Makefile La documentation sur pkgsrc : http://www.netbsd.org/Documentation/pkgsrc/ , http://www.netbsd.org/Documentation/software/packages.html