Empaquette-moi le codaz @#!@#!

GNU/Linux Magazine HS n° 030 | mai 2007 | Landry (gaston) Breuil
Creative Commons
  • Actuellement 0 sur 5 étoiles
0
Merci d'avoir participé !
Vous avez déjà noté cette page, vous ne pouvez la noter qu'une fois !
Votre note a été changée, merci de votre participation !
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/produit.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) :

landry@renton:~ $ls -FR /usr/ports/archivers/unrar

Makefile distinfo patches/ pkg/

/usr/ports/archivers/unrar/patches:

patch-makefile_unix   patch-rar_hpp         patch-suballoc_cpp

/usr/ports/archivers/unrar/pkg:

DESCR PLIST

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 :

landry@renton:/usr/ports/archivers/unrar/ $sudo make install clean

===> Checking files for unrar-3.68p0

>> unrarsrc-3.6.8.tar.gz doesn't seem to exist on this system.

>> Fetch www.rarlab.com/rar/unrarsrc-3.6.8.tar.gz.

100% ||   122 KB    00:01    

>> Size matches for /usr/ports/distfiles/unrarsrc-3.6.8.tar.gz

>> Checksum OK for unrarsrc-3.6.8.tar.gz. (sha1)

===> Verifying specs: c m stdc++ c m stdc++

===> found c.40.3 m.2.3 stdc++.42.0

===> Extracting for unrar-3.68p0

===> Patching for unrar-3.68p0

===> Configuring for unrar-3.68p0

===> Building for unrar-3.68p0

c++ -O2 -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DUNRAR -c rar.cpp

....

strip unrar

===> Faking installation for unrar-3.68p0

install -c -s -o root -g bin -m 555 /usr/ports/archivers/unrar/w-unrar-3.68p0/unrar/unrar /usr/ports/archivers/unrar/w-unrar-3.68p0/fake-i386/usr/local/bin

install -d -o root -g bin -m 755 /usr/ports/archivers/unrar/w-unrar-3.68p0/fake-i386/usr/local/share/doc/unrar

install -c -o root -g bin -m 444 /usr/ports/archivers/unrar/w-unrar-3.68p0/unrar/readme.txt /usr/ports/archivers/unrar/w-unrar-3.68p0/unrar/license.txt /usr/ports/archivers/unrar/w-unrar-3.68p0/fake-i386/usr/local/share/doc/unrar

===> Building package for unrar-3.68p0

Create /usr/ports/packages/i386/all/unrar-3.68p0.tgz

===> Verifying specs: c m stdc++

===> found c.40.3 m.2.3 stdc++.42.0

===> Installing unrar-3.68p0 from /usr/ports/packages/i386/all/

unrar-3.68p0: complete                                                                                                              

===> Cleaning for unrar-3.68p0

$

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}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.

landry@renton:/usr/ports/ $make search name=grisbi

landry@renton:/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 :

# $OpenBSD$

COMMENT =      "Personal accounting application"

VERSION =      0.5.9

DISTNAME =     grisbi-${VERSION}

CATEGORIES =   productivity

EXTRACT_SUFX = .tar.bz2

MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=grisbi/}

HOMEPAGE =     http://www.grisbi.org/

MAINTAINER =   Landry Breuil <gaston@gcu.info>

# GPL

PERMIT_PACKAGE_CDROM =   Yes

PERMIT_PACKAGE_FTP =     Yes

PERMIT_DISTFILES_CDROM = Yes

PERMIT_DISTFILES_FTP =   Yes

.include <bsd.port.mk>

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 :

landry@renton:/usr/ports/mystuff/grisbi/ $make fetch extract

===> Checking files for grisbi-0.5.9

>> grisbi-0.5.9.tar.bz2 doesn't seem to exist on this system.

>> Fetch downloads.sourceforge.net/grisbi/grisbi-0.5.9.tar.bz2.

100% ||   979 KB    00:04    

>> Checksum file does not exist

===> Checking files for grisbi-0.5.9

'/usr/ports/distfiles/grisbi-0.5.9.tar.bz2' is up to date.

>> No checksum file.

* Error code 1

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é.

===> Checking files for grisbi-0.5.9

'/usr/ports/distfiles/grisbi-0.5.9.tar.bz2' is up to date.

>> Checksum OK for grisbi-0.5.9.tar.bz2. (sha1)

===> grisbi-0.5.9 depends on: bzip2-* - found

===> Extracting for grisbi-0.5.9

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.

# configure stuff

CONFIGURE_STYLE = gnu

USE_GMAKE =       Yes

USE_X11 =         Yes

Hop, un coup de make configure, et les ennuis s’approchent à grands pas. Globalement, ça se passe bien, sauf pour ça :

checking libofx/libofx.h usability... no

checking libofx/libofx.h presence... no

checking for libofx/libofx.h... no

Libofx header missing. Check your libofx installation

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) :

# $OpenBSD$

COMMENT =      "library to access OFX files"

VERSION =      0.8.3

DISTNAME =     libofx-${VERSION}

CATEGORIES =   textproc

MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=libofx/}

HOMEPAGE =     http://libofx.sourceforge.net/

MAINTAINER =   Landry Breuil <gaston@gcu.info>

# GPL

PERMIT_PACKAGE_CDROM =   Yes

PERMIT_PACKAGE_FTP =     Yes

PERMIT_DISTFILES_CDROM = Yes

PERMIT_DISTFILES_FTP =   Yes

USE_LIBTOOL=            Yes

CONFIGURE_STYLE=        gnu

.include <bsd.port.mk>

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.

checking for ParserEventGenerator.h in /usr/include/OpenSP... no

checking for ParserEventGenerator.h in /usr/local/include/OpenSP... no

checking for ParserEventGenerator.h in /usr/include/sp/generic... no

checking for ParserEventGenerator.h in /usr/local/include/sp/generic... no

checking for ParserEventGeneratorKit.h... no

configure: error: OpenSP includes not found

* Error code 1

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.

# on fait un backup de l'original pour la création du patch

landry@renton:/usr/ports/mystuff/libofx/ $cp w-libofx-0.8.3/libofx-0.8.3/configure{,.orig}

# on remplace avec son éditeur préféré -lsp par -losp.

landry@renton:/usr/ports/mystuff/libofx/ $vi w-libofx-0.8.3/libofx-0.8.3/configure

...

landry@renton:/usr/ports/mystuff/libofx/ $make update-patches

Processing configure

No patch-* found for configure, creating patch-configure

# on nous propose d'éditer le patch... osef.

landry@renton:/usr/ports/mystuff/libofx/ $cat patches/patch-configure

$OpenBSD$

--- configure.orig      Thu Mar 8 00:02:48 2007

+++ configure   Thu Mar 8 00:07:12 2007

@@ -20639,7 +20639,7 @@ fi

done

-OPENSPLIBS="-L$OPENSPLIBPATH -losp"

+OPENSPLIBS="-L$OPENSPLIBPATH -lsp"

ac_save_LIBS="$LIBS"

LIBS="$OPENSPLIBS $LIBS"

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 :

# ${LOCALBASE} correspond à /usr/local

# là où tous les ports sont installés sous OpenBSD

# => la source de la vie.

CONFIGURE_ENV= LDFLAGS="-L${LOCALBASE}/lib -lm"

CONFIGURE_ARGS= ${CONFIGURE_SHARED} \

                --with-opensp-libs=${LOCALBASE}/lib \

                --with-opensp-includes=${LOCALBASE}/include/sp \

                --without-libcurl \

                --disable-doxygen \

                --disable-dot \

                --disable-gengetopt

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 :

landry@renton:/usr/ports/mystuff/libofx/ $make update-plist

===> Updating plist for libofx-0.8.3

WARNING: unregistered shared lib: ofx (version: 3.1)

/usr/ports/mystuff/libofx/pkg/PLIST is new

/usr/ports/mystuff/libofx/pkg/PFRAG.shared is new

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.

landry@renton:/usr/ports/mystuff/libofx/ $make clean lib-depends-check

===> Checking files for libofx-0.8.3

`/usr/ports/distfiles/libofx-0.8.3.tar.gz' is up to date.

>> Checksum OK for libofx-0.8.3.tar.gz. (sha1)

===> libofx-0.8.3 depends on: libtool-* - found

===> Extracting for libofx-0.8.3

===> Patching for libofx-0.8.3

===> Configuring for libofx-0.8.3

.....

===> Building for libofx-0.8.3

.....

===> Faking installation for libofx-0.8.3

.....

===> Building package for libofx-0.8.3

.....

/usr/ports/packages/i386/all/libofx-0.8.3.tgz:

Missing system lib: c.40 (/usr/local/bin/ofxdump)

Missing system lib: m.2 (/usr/local/bin/ofxdump)

Missing system lib: stdc++.42 (/usr/local/bin/ofxdump)

        WANTLIB += c m stdc++

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 :

# dependencies

SHARED_LIBS = ofx 3.1

WANTLIB =     c m stdc++

LIB_DEPENDS = ::textproc/sp

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.

# configure stuff

CONFIGURE_ENV = LDFLAGS="-L${LOCALBASE}/lib -lofx -lsp" \

   CPPFLAGS="-I${LOCALBASE}/include"

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...

landry@renton:/usr/ports/mystuff/grisbi/ $make update-plist

===> Faking installation for grisbi-0.5.9

.....

===> Updating plist for grisbi-0.5.9

/usr/ports/mystuff/grisbi/pkg/PLIST is new

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.

[22:54:23] landry@renton:/usr/ports/mystuff/grisbi/ $make lib-depends-check

===> Building package for grisbi-0.5.9

Create /usr/ports/packages/i386/all/grisbi-0.5.9.tgz

Link to /usr/ports/packages/i386/ftp/grisbi-0.5.9.tgz

Link to /usr/ports/packages/i386/cdrom/grisbi-0.5.9.tgz

/usr/ports/packages/i386/all/grisbi-0.5.9.tgz:

Missing system lib: X11.9 (/usr/local/bin/grisbi)

Missing system lib: Xext.9 (/usr/local/bin/grisbi)

Missing system lib: Xrender.4 (/usr/local/bin/grisbi)

Missing: atk-1.0.1011 (/usr/local/bin/grisbi): NOT REACHABLE

Missing system lib: c.40 (/usr/local/bin/grisbi)

Missing: cairo.5 (/usr/local/bin/grisbi): NOT REACHABLE

Missing system lib: fontconfig.3 (/usr/local/bin/grisbi)

Missing system lib: freetype.13 (/usr/local/bin/grisbi)

Missing: gdk-x11-2.0.802 (/usr/local/bin/grisbi): NOT REACHABLE

Missing: gdk_pixbuf-2.0.802 (/usr/local/bin/grisbi): NOT REACHABLE

Missing: glib-2.0.1000 (/usr/local/bin/grisbi): NOT REACHABLE

Missing: glitz.2 (/usr/local/bin/grisbi): NOT REACHABLE

Missing: gmodule-2.0.1000 (/usr/local/bin/grisbi): NOT REACHABLE

Missing: gobject-2.0.1000 (/usr/local/bin/grisbi): NOT REACHABLE

Missing: gtk-x11-2.0.802 (/usr/local/bin/grisbi): NOT REACHABLE

Missing: iconv.4 (/usr/local/bin/grisbi): NOT REACHABLE

Missing: intl.3 (/usr/local/bin/grisbi): NOT REACHABLE

Missing system lib: m.2 (/usr/local/bin/grisbi)

Missing: ofx.3 (/usr/local/bin/grisbi): NOT REACHABLE

Missing: pango-1.0.1200 (/usr/local/bin/grisbi): NOT REACHABLE

Missing: pangocairo-1.0.1200 (/usr/local/bin/grisbi): NOT REACHABLE

Missing: pangoft2-1.0.1200 (/usr/local/bin/grisbi): NOT REACHABLE

Missing: png.5 (/usr/local/bin/grisbi): NOT REACHABLE

Missing system lib: stdc++.42 (/usr/local/bin/grisbi)

Missing: xml2.9 (/usr/local/bin/grisbi): NOT REACHABLE

Missing system lib: z.4 (/usr/local/bin/grisbi)

        WANTLIB += X11 Xext Xrender c fontconfig freetype m stdc++ z

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.

===> grisbi-0.5.9 depends on: gettext->=0.14.6 - found

===> grisbi-0.5.9 depends on: gmake-* - found

===> grisbi-0.5.9 depends on: bzip2-* - found

===> grisbi-0.5.9 depends on: gettext->=0.10.38 - found

===> grisbi-0.5.9 depends on: libiconv-* - found

===> Verifying specs: intl.>=3 iconv.>=4 intl.>=3 iconv.>=4 X11 Xext Xrender c fontconfig freetype m stdc++ z X11 Xext Xrender c fontconfig freetype m stdc++ z

===> found intl.3.0 iconv.4.0 X11.9.0 Xext.9.0 Xrender.4.1 c.40.3 fontconfig.3.0 freetype.13.1 m.2.3 stdc++.42.0 z.4.1

===> Extracting for grisbi-0.5.9

...

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, tout 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.

# dependencies

MODULES = devel/gettext

WANTLIB = X11 Xext Xrender c fontconfig freetype m stdc++ z \

   atk-1.0 cairo glib-2.0 glitz gmodule-2.0 gobject-2.0 \

   pango-1.0 pangocairo-1.0 pangoft2-1.0 png

LIB_DEPENDS = xml2.>=9::textproc/libxml \

   gdk-x11-2.0,gdk_pixbuf-2.0,gtk-x11-2.0::x11/gtk+2 \

   ofx.>=3::devel/libofx

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 WANTLIBpour les dépendances « indirectes », aka. les dépendances des dépendances... Pas bête, non ?

Hop, on reteste...

landry@renton:/usr/ports/mystuff/grisbi/ $make lib-depends-check                          

===> Checking files for grisbi-0.5.9

`/usr/ports/distfiles/grisbi-0.5.9.tar.bz2' is up to date.

>> Checksum OK for grisbi-0.5.9.tar.bz2. (sha1)

===> Verifying specs: atk-1.0 gmodule-2.0 gobject-2.0 glib-2.0 pango-1.0 pangocairo-1.0 pangoft2-1.0 gdk-x11-2.0 gdk_pixbuf-2.0 gtk-x11-2.0 cairo glitz png xml2 ofx intl.>=3 iconv.>=4 Xext Xrender c fontconfig freetype m stdc++ z

===> found atk-1.0.1011.3 gmodule-2.0.1000.3 gobject-2.0.1000.3 glib-2.0.1000.3 pango-1.0.1200.3 pangocairo-1.0.1200.3 pangoft2-1.0.1200.3 gdk-x11-2.0.802.1 gdk_pixbuf-2.0.802.1 gtk-x11-2.0.802.1 cairo.5.0 glitz.2.0 png.5.1 xml2.9.3 ofx.3.1 intl.3.0 iconv.4.0 X11.9.0 Xext.9.0 Xrender.4.1 c.40.3 fontconfig.3.0 freetype.13.1 m.2.3 stdc++.42.0 z.4.1

===> Extracting for grisbi-0.5.9

===> Patching for grisbi-0.5.9

===> Configuring for grisbi-0.5.9

...

===> Building package for grisbi-0.5.9

Create /usr/ports/packages/i386/all/grisbi-0.5.9.tgz

Link to /usr/ports/packages/i386/ftp/grisbi-0.5.9.tgz

Link to /usr/ports/packages/i386/cdrom/grisbi-0.5.9.tgz

/usr/ports/packages/i386/all/grisbi-0.5.9.tgz:

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 !

Linqses

- man (5) bsd.port.mk

- man (7) ports

- Écrire un port

- Tester un port

- Checklist

- Archive de ports@openbsd.org

- Le port de libofx

- Le port de grisbi

Pkgsrc NetBSD

Introduction

Un bon exemple vaut mieux qu’on 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 :

# cd /usr/pkgsrc/pkgtools/url2pkg

# make install clean

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.

# mkdir -p /usr/pkgsrc/wip/vlock

Maintenant que le nid est prêt, on va y mettre les meubles :

# cd /usr/pkgsrc/wip/vlock

# url2pkg http://www.bedis.eu/NetBSD/vlock-1.3.tar.gz

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 :

# ls -l

total 10

-rw-r--r--   1 root wheel    0 Mar 10 01:22 DESCR

-rw-r--r--   1 root wheel 213 Mar 10 01:23 Makefile

-rw-r--r--   1 root wheel 264 Mar 10 01:23 Makefile~

-rw-r--r--   1 root wheel   18 Mar 10 01:22 PLIST

-rw-r--r--   1 root wheel 184 Mar 10 01:23 distinfo

drwxr-xr-x 10 root wheel 512 Mar 10 01:23 work

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 :

DISTNAME=       vlock-1.3

CATEGORIES=     wip

MASTER_SITES=   http://www.bedis.eu/NetBSD/

MAINTAINER=     INSERT_YOUR_MAIL_ADDRESS_HERE

HOMEPAGE=       http://www.bedis.eu/NetBSD/

COMMENT=        SHORT_DESCRIPTION_OF_THE_PACKAGE

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 :

$ make

gcc -O2 -DUSE_PAM -c vlock.c

vlock.c:20:20: sys/vt.h: No such file or directory

vlock.c:21:20: sys/kd.h: No such file or directory

vlock.c: In function `main':

vlock.c:49: error: storage size of `vtm' isn't known

[...]

Tout d’abord, créez une copie de vlock.c, qui nous permettra de créer le patch.

$ cp vlock.c vlock.c.orig

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.

Et hop, on re-make :

$ make

gcc -O2 -DUSE_PAM -c vlock.c

gcc -O2 -DUSE_PAM -c signals.c

signals.c:19:20: sys/vt.h: No such file or directory

signals.c: In function `release_vt':

[...]

Bon, vlock.c passe maintenant, appliquons la même séquence à signals.c !

Et re-make :

$ make

gcc -O2 -DUSE_PAM -c vlock.c

gcc -O2 -DUSE_PAM -c signals.c

gcc -O2 -DUSE_PAM -c help.c

gcc -O2 -DUSE_PAM -c terminal.c

terminal.c:18:20: sys/vt.h: No such file or directory

terminal.c: In function `restore_terminal':

[...]

Bon, encore ce bloody sys/vt.h... On applique la même procédure là encore !

Et on repart :

$ make

gcc -O2 -DUSE_PAM -c signals.c

gcc -O2 -DUSE_PAM -c terminal.c

gcc -O2 -DUSE_PAM -c input.c

input.c:64:31: security/pam_misc.h: No such file or directory

input.c:67: error: `misc_conv' undeclared here (not in a function)

[...]

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 !)

$ make

gcc -O2 -DUSE_PAM -c vlock.c

gcc -O2 -DUSE_PAM -c signals.c

gcc -O2 -DUSE_PAM -c help.c

gcc -O2 -DUSE_PAM -c terminal.c

gcc -O2 -DUSE_PAM -c input.c

gcc -O2 -DUSE_PAM -ldl -lpam -lpam_misc -o vlock vlock.c

ld: cannot find -ldl

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 :

# vlock makefile

CFLAGS += -DUSE_PAM

LDFLAGS = -lpam

OBJS = vlock.o signals.o help.o terminal.o input.o

all: vlock

vlock.man: vlock.1

        groff -man -Tascii vlock.1 > vlock.man

vlock: $(OBJS)

        cc $(OBJS) $(LDFLAGS) -o vlock

clean:

        rm -f ${OBJS} vlock vlock.core

et un dernier make pour vérifier que tout se passe bien :

$ make

cc -O2 -DUSE_PAM -c vlock.c

cc -O2 -DUSE_PAM -c signals.c

cc -O2 -DUSE_PAM -c help.c

cc -O2 -DUSE_PAM -c terminal.c

cc -O2 -DUSE_PAM -c input.c

cc vlock.o signals.o help.o terminal.o input.o -lpam -o vlock

\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.

# mkdir /usr/pkgsrc/wip/vlock/patches

Depuis le répertoire où l’on a travaillé notre bébé, préparez le papier peint :

diff -bu vlock.c.orig vlock.c > /usr/pkgsrc/wip/vlock/patches/patch-aa

diff -bu signals.c.orig signals.c > /usr/pkgsrc/wip/vlock/patches/patch-ab

diff -bu terminal.c.orig terminal.c > /usr/pkgsrc/wip/vlock/patches/patch-ac

diff -bu input.c.orig input.c > /usr/pkgsrc/wip/vlock/patches/patch-ad

diff -bu Makefile.orig Makefile > /usr/pkgsrc/wip/vlock/patches/patch-ae

Et on fait les finitions. Exécutez cette commande dans le répertoire du package :

# make makepatchsum

Ca va permettre de mettre à jour le fichier distinfo avec les hash des patches :

$ cat distinfo

$NetBSD$

SHA1 (vlock-1.3.tar.gz) = 5da5f905bbba1c8dbcae0513668c46c908a1089e

RMD160 (vlock-1.3.tar.gz) = 434ec6613476efb9386597ac44857d993fb70d47

Size (vlock-1.3.tar.gz) = 17188 bytes

SHA1 (patch-aa) = f827d27a07d17cb92bbb57a40d0a729d56da097a

SHA1 (patch-ab) = 58811ac2eab370a1113710d469ec9162fb5846b5

SHA1 (patch-ac) = 84c2b134db608f241f18b9ea890040f5ad49c3c7

SHA1 (patch-ad) = 6c3207a72ba91795e60d30920e2f17c76c58fb6d

SHA1 (patch-ae) = ad7ae98a10f5c8d53fa6599ce90e3aa89575fead

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 :

do-install:

        ${INSTALL_PROGRAM} -c -s -o root -g wheel -m 4555 ${WRKDIR}/${DISTNAME}/vlock ${PREFIX}/bin

        ${INSTALL_MAN} ${WRKSRC}/vlock.1 ${PREFIX}/${PKGMANDIR}/man1

Maintenant, on teste l’installation. Exécuter directement dans le répertoire du package :

$ sudo make install

=> Required installed package digest>=20010302: digest-20060826 found

===> Skipping vulnerability checks.

WARNING: No /usr/pkgsrc/distfiles/pkg-vulnerabilities file found.

WARNING: To fix, install the pkgsrc/security/audit-packages

WARNING: package and run: ``/usr/pkg/sbin/download-vulnerability-list''.

=> Fetching vlock-1.3.tar.gz

=> Total size: 17188 bytes

Requesting http://www.bedis.eu/NetBSD/vlock-1.3.tar.gz

100% |********************************************************| 17188      84.76 KB/s    00:00 ETA

17188 bytes retrieved in 00:00 (84.69 KB/s)

=> Checksum SHA1 OK for vlock-1.3.tar.gz

=> Checksum RMD160 OK for vlock-1.3.tar.gz

===> Installing dependencies for vlock-1.3

===> Overriding tools for vlock-1.3

===> Extracting for vlock-1.3

===> Patching for vlock-1.3

=> Applying pkgsrc patches for vlock-1.3

===> Creating toolchain wrappers for vlock-1.3

===> Configuring for vlock-1.3

===> Building for vlock-1.3

cc -O2 -DUSE_PAM -c vlock.c

cc -O2 -DUSE_PAM -c signals.c

cc -O2 -DUSE_PAM -c help.c

cc -O2 -DUSE_PAM -c terminal.c

cc -O2 -DUSE_PAM -c input.c

cc vlock.o signals.o help.o terminal.o input.o -lpam -o vlock

=> Unwrapping files-to-be-installed.

===> Installing for vlock-1.3

/usr/bin/install -c -s -o root -g wheel -m 555 -c -s -o root -g wheel -m 4555 /usr/pkgsrc/wip/vlock/work/vlock-1.3/vlock /usr/pkg/bin

/usr/bin/install -c -o root -g wheel -m 444 /usr/pkgsrc/wip/vlock/work/vlock-1.3/vlock.1 /usr/pkg/man/man1

=> Automatic manual page handling

=> Registering installation for vlock-1.3

Le premier jour d’école du petit s’est bien déroulé. Il est dans la classe, avec ses potes.

$ pkg_info vlock

Information for vlock-1.3:

Comment:

Terminal lock

Description:

Homepage:

http://www.bedis.eu/NetBSD/

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 :

# make makedistinfo

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-XXX 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.

# cp monsource.c monsource.c.orig

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 :

/usr/pkgsrc/wip/vlock$ sudo mkpatches -d ./patches/ -v

patch-aa -> /usr/pkgsrc/wip/vlock/work/vlock-1.3/Makefile

patch-ab -> /usr/pkgsrc/wip/vlock/work/vlock-1.3/input.c

patch-ac -> /usr/pkgsrc/wip/vlock/work/vlock-1.3/signals.c

patch-ad -> /usr/pkgsrc/wip/vlock/work/vlock-1.3/terminal.c

patch-ae -> /usr/pkgsrc/wip/vlock/work/vlock-1.3/vlock.c

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 :

/usr/pkgsrc/wip/vlock$ sudo make install

=> Required installed package digest>=20010302: digest-20060826 found

===> Skipping vulnerability checks.

WARNING: No /usr/pkgsrc/distfiles/pkg-vulnerabilities file found.

WARNING: To fix, install the pkgsrc/security/audit-packages

WARNING: package and run: ``/usr/pkg/sbin/download-vulnerability-list''.

=> Checksum SHA1 OK for vlock-1.3.tar.gz

=> Checksum RMD160 OK for vlock-1.3.tar.gz

===> Installing for vlock-1.3

/usr/bin/install -c -s -o root -g wheel -m 555 -c -s -o root -g wheel -m 4555 /usr/pkgsrc/wip/vlock/work/vlock-1.3/vlock /usr/pkg/bin

/usr/bin/install -c -o root -g wheel -m 444 /usr/pkgsrc/wip/vlock/work/vlock-1.3/vlock.1 /usr/pkg/man/man1

=> Automatic manual page handling

=> Registering installation for vlock-1.3

/usr/pkgsrc/wip/vlock$ sudo make print-PLIST

@comment $NetBSD$

bin/vlock

man/man1/vlock.1

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 :

/usr/pkgsrc/wip/vlock$ sudo make package

=> Required installed package digest>=20010302: digest-20060826 found

===> Skipping vulnerability checks.

WARNING: No /usr/pkgsrc/distfiles/pkg-vulnerabilities file found.

WARNING: To fix, install the pkgsrc/security/audit-packages

WARNING: package and run: ``/usr/pkg/sbin/download-vulnerability-list''.

=> Checksum SHA1 OK for vlock-1.3.tar.gz

=> Checksum RMD160 OK for vlock-1.3.tar.gz

===> Building binary package for vlock-1.3

Creating package /usr/pkgsrc/packages/All/vlock-1.3.tgz

Using SrcDir value of /usr/pkg

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/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