OpenBSD Ports: Porting Guide : (v1.93 ; 11/12/2020)
— [ FAQ Index ] | [ Index Ports ] ~ Traduction française de la page OpenBSD Ports : Guide de Portage —
Ainsi, vous venez de compiler votre package de logiciel préféré sur votre machine OpenBSD et vous voulez partager vos efforts en le transformant en port standard. Que faire ?
La plus importante des choses à faire est de communiquer. Demandez aux personnes sur ports@openbsd.org s'ils travaillent sur le même port. Parlez-en aux auteurs du logiciel, y compris des problèmes que vous pourriez rencontrer. Si les renseignements sur la licence semblent inexacts, dites-leur. Si vous avez rencontré des difficultés pour faire la construction du port, dites-leur ce qui peut être corrigé. S'ils ne développent que sous Linux et semblent ignorer le reste du monde Unix, essayez de les faire changer d'avis.
La communication fait la différence entre un port qui réussi et un port qui sera lentement abandonné par tous.
Tout d'abord, regardez les informations de portage sur cette page. Testez, re-testez encore, et finalement testez à nouveau !
OpenBSD supporte pleinement les mises à jours. Cela signifie que certains problèmes doivent être pris en compte.
Soumettez le port. Créez une archive tar gzip du répertoire du port. Vous pouvez alors soit le placer sur un serveur HTTP public, en envoyant son URL à ports@openbsd.org, soit envoyer le port MIME encodé à la même adresse.
Portez certains nouveaux logiciel prend du temps. Le maintenir dans le temps est encore plus difficile. Il est tout à fait correct de porter le logiciel et de laisser d'autres personnes s'en occuper après. Il est également correct d'aider les autres personnes à mettre à jour et maintenir d'autres ports, tant que vous communiquez pour éviter de faire les mêmes choses deux fois.
Dans la culture d'OpenBSD, le rôle de RESPONSABLE n'est pas un statut, mais une responsabilité. Nous avons CVS et les commentaires pour donner du crédit à la personne qui a fait le travail. Un RESPONSABLE de port est ceci : une personne qui assume la responsabilité du fonctionnement du port et qui est prête à passer un certain temps pour s'assurer qu'il fonctionne le mieux possible.
La liste ci-dessous est utile pour se rappeler des choses à faire. Elle n'est ni totalement exacte, ni parfaite. Envoyez vos commentaires et vos questions à ports@openbsd.org.
/usr/ports/
, choisissez une catégorie primaire pour votre port. Créez un nouveau répertoire sous /usr/ports/<category>/
ou /usr/ports/mystuff/<category>/
et créez-y l'infrastructure de base. Copiez le modèle du fichier Makefile
depuis /usr/ports/infrastructure/templates/Makefile.template
. Remplissez la valeur CATEGORIES
par la première catégorie que vous avez choisie. EXTRACT_SUFX
si elle est autre que .tar.gz. D'autres exemples sont .tar.Z, ou .tgz. DISTNAME
par le nom du fichier moins la valeur du suffixe d'extraction. Si vous avez foo-1.0.tar.gz
, DISTNAME
est foo-1.0
.MASTER_SITES
avec une liste d'URL aux endroits où le fichier distfile est conservé, par exemple https://ftp.openbsd.org/pub/OpenBSD/distfiles/. N'oubliez pas la barre oblique. Essayez d'avoir au moins trois sites distincts. Placez le plus accessible en premier car ils sont parcourus dans l'ordre. ${MASTER_SITES}${DISTNAME}${EXTRACT_SUFX}
. Les trois sont utilisées. Ne paramétrez pas DISTNAME
pour pointer directement vers le fichier. make makesum
. PATCHFILES
. Ceci est une liste de correctifs venant de l'auteur (qui ne fait pas partie d'OpenBSD) à appliquer au port. Les utilisations courantes sont en rapport avec les correctifs de sécurité ou de fiabilité qui sont occasionnellement distribués en tant que correctifs plutôt qu'en versions complètes. /usr/ports/infrastructure/db/network.conf
. Paramétrez MASTER_SITES
à ${MASTER_SITE_GNU}
, ou ${MASTER_SITE_SOURCEFORGE}
, etc. Pour simplifier ce processus, utilisez la notation ${MASTER_SITE_FOO:=subdir/}
pour ajouter le sous-répertoire de distribution. MASTER_SITES=https://github.com/acct/project/releases/download/relname/
. GH_ACCOUNT
, GH_PROJECT
, GH_TAGNAME
. Le nom de fichier fourni est rarement approprié pour une utilisation directe en tant que DISTNAME
, n'ayant fréquemment que seul le numéro de version ; ils peuvent être renommés au moment du téléchargement en utilisant la notation “{}” dans DISTFILES
. GH_COMMIT
devrait être utilisé à la place de GH_TAGNAME
. DISTFILES
et PATCHFILES
devraient avoir clairement des versions de numéro visibles : ne récupérez pas foo-latest.tar.gz
si c'est un lien vers foo-1.0.5.tar.gz
. Les noms de fichiers ne doivent pas contenir juste le numéro de version (1.0.5.tar.gz
); les fichiers peuvent être renommés lors de la récupération si nécessaire, voire bsd.port.mk(5). Si une information n'est disponible que dans un fichier non versionné, demandez gentiment à l'auteur du programme original de faire clairement ces distinctions. Dans l'intervalle, si vous devez utiliser un fichier comme celui-ci, réglez DIST_SUBDIR
sur ce que serait un DISTNAME
raisonnable, tel que foo-1.0.5
, de telle sorte que les différentes versions du fichier distfile portant le même nom n'entrent pas en conflit sur les miroirs du fichier de distribution ou les machines de construction. DISTFILES
et PATCHFILES
pour fonctionner, utilisez DIST_SUBDIR
pour éviter de trop encombrer DISTDIR
(/usr/ports/distfiles
par défaut). Dans ce cas, DIST_SUBDIR
ne doit pas inclure de numéros de version. Quand le port est mis à jour vers la dernière version, quelques fichiers distfiles peuvent ne pas changer, mais ils seront récupérés si DIST_SUBDIR
est changé. Même si tous les fichiers distfiles changent, il est plus facile pour l'utilisateur de faire du dépoussiérage. DISTFILES
et PATCHFILES
ne viennent pas nécessairement du même ensemble de MASTER_SITES
. Des sites supplémentaires peuvent être définis en utilisant les variables MASTER_SITES0
à MASTER_SITES9
. Écrivez simplement DISTFILES=foo-1.0.5.tar.gz:5
pour récupérer foo-1.0.5.tar.gz
depuis MASTER_SITES5
. SUPDISTFILES
. Des cibles telles que makesum
ou mirror-distfiles
récupéreront ces fichiers supplémentaires dont l'utilisateur occasionnel n'a pas besoin. distinfo
en tapant make makesum
. Puis, vérifiez que la somme de contrôle soit correcte en tapant make checksum
. IGNOREFILES
. DISTFILES
sont habituellement traités durant make extract
. EXTRACT_ONLY
peut être utilisé pour limiter l'extraction d'un sous-ensemble de fichiers (éventuellement vide). L'utilisation habituelle de cette variable est de personnaliser l'extraction : par exemple, si certains DISTFILES
ont besoin de traitement spécifique, ils peuvent être enlevés de EXTRACT_ONLY
et manipulé manuellement au stade post-extract
. Pour des raisons historiques, make extract
configure d'abord le répertoire de travail lors de l'extraction des fichiers. Cela étant, fournir une cible pre-extract
ou do-extract
est hautement inhabituel (et est un comportement assez suspect, révélateur d'un haut degré d'obscurcissement dans le port).DISTFILES
, et supprimés depuis EXTRACT_ONLY
. make extract
. Prêtez attention à l'endroit où se trouvent la base des sources. Habituellement, c'est dans /usr/ports/pobj/${PKGNAME}${FLAVOR_EXT}${DISTNAME}
. Vous pouvez avoir besoin de modifier la variable WRKDIST
du fichier Makefile
si cela est différent. PERMIT_*
dans le fichier Makefile
. PERMIT_PACKAGE_CDROM
nous dit si nous pouvons mettre à disposition le package sur cdrom. PERMIT_PACKAGE_FTP
nous dit si nous pouvons mettre à disposition le package sur sites par ftp. PERMIT_PACKAGE_CDROM=Yes
. Autrement paramètrez chacune des variables soit sur Yes
, ou mettez un commentaire indiquant la raison pour laquelle la distribution n'est pas autorisée. Prêtez attention aux conditions spéciales que vous pourriez avoir à remplir plus tard. Par exemple, certains ports requièrent d'installer une copie de la licence. Nous vous recommandons de placer la licence dans /usr/local/share/doc/<name>/
. PERMIT_*
, déposez un marqueur de licence tel que #License
au-dessus en tant que commentaire, de cette manière nous savons pourquoi les valeurs PERMIT_*
sont ainsi paramétrées. Pour la GPL, spécifiez quelle version est applicable, p. ex. “GPLv2 only”, “GPLv2+” (signifiant “v2 ou plus récent”), “GPLv3 only”, etc. Makefile
et/ou créez les scripts de configuration. ./configure –help
pour voir quelles options sont disponibles. En particulier, regardez quelles dépendances optionnelles peuvent ne pas être présentes sur votre système, mais peuvent être obtenues sur un autre systme ou dans une autre construction. –option
au paramètre CONFIGURE_ARGS
dans le Makefile
. CONFIGURE_ARGS+=
pour ajouter à la variable. CONFIGURE_ARGS=
l'écrasera. make build
. cd `make show=WRKSRC` ; cp foo/bar.c{,.orig}
foo/bar.c
pour corriger l'erreur.cd - ; make update-patches
patches/patch-foo_bar_c
avec vos modifications. make clean patch
. make build
, générez un correctif en utilisant make update-patches
et make clean patch
. patches/
et devraient être nommés patch-* - * étant une chaîne de caractères significative. La manière préférée pour le nommer est patch-FILENAME
, où FILENAME
est le nom du fichier qui est corrigé (make update-patches
fait cela automatiquement pour vous).PATCHFILES
est la première moitié de l'étape du make patch
. Il peut être invoqué séparément comme make distpatch
, qui est une cible pratique pour les porteurs. Ignorez ceci si vous ne l'avez pas paramétré. make update-patches
pour générer les correctifs. -kk
pour éviter cela. SEPARATE_BUILD
. CONFIGURE_STYLE=gnu
le peuvent), et cela peut aider les personnes qui montent leur arborescence de ports sur plusieurs architectures. Makefile
. Pour répéter, utilisez la commande make clean configure
. /etc
ou /etc/<name>
, mais ne doivent JAMAIS REMPLACER OU MODIFIER des fichiers existants dans /etc
. Il est mieux de les installer dans /usr/local/share/<name>
puis de les copier dans /etc
si seulement ils n'existent pas. Si les fichiers existent, affichez un message qui informe que tels et tels fichiers ont besoin d'être modifiés. Cela garantit aussi que les fichiers seront inclus dans le package puisque tout ce qui est sous /usr/local
est inclus dans le fichier PLIST
. Pour manipuler la copie avec précaution, le mot-clé @sample
est de préférence utilisé dans le PLIST
. Après qu'un package ait été installé, le contenu de pkg/MESSAGE
sera affiché s'il existe. user executables: /usr/local/bin system admin executables: /usr/local/sbin program executables: /usr/local/libexec libraries: /usr/local/lib architecture dependent data: /usr/local/lib/<name> installed include files: /usr/local/include or /usr/local/include/<name> single-machine data: /etc or /etc/<name> local state: /var/run games score files: /var/games GNU info files: /usr/local/info man pages: /usr/local/man/... read-only architecture-independent: /usr/local/share/<name> misc documentation: /usr/local/share/doc/<name> examples files: /usr/local/share/examples/<name>
SEPARATE_BUILD
. Vous devez faire cela seulement si le port est construit avec SEPARATE_BUILD
défini. Idéalement, le port ne devrait modifier aucun fichier dans ${WRKSRC}
après make patch
. Vous pouvez vérifier cela en vous assurant de ne pas avoir d'accès en écriture sur ${WRKSRC}
. Alors, vous pouvez paramétrer SEPARATE_BUILD=concurrent
. Une personne peut utiliser la même arborescence des sources pour construire sur des architectures différentes simultanément. Autrement, paramétrez SEPARATE_BUILD=simple
. Construire sur des arches distinctes simultanément peut poser des problèmes, car certains fichiers sources peuvent être régénérés à des moments gênants. COMMENT
dans le Makefile
. COMMENT est une COURTE description du port en une ligne (max. 60 caractères). N'incluez PAS le nom du package (ou le numéro de version du logiciel) dans le commentaire. NE démarrez PAS avec une lettre majuscule à moins que cela soit significatif sémantiquement, et NE terminez PAS avec un point. NE JAMAIS DÉMARREZ AVEC UN ARTICLE INDÉFINI TEL QUE “a” OU “an” - supprimez l'article complètement. pkg/DESCR
. De un à quelques paragraphes, expliquant brièvement ce que le port fait, est suffisant. Les lignes ne devraient pas avoir une longueur de plus de 80 caractères. Cela peut être fait en commençant par éditer le fichier DESCR
puis en exécutant dessus fmt
. /usr/ports/infrastructure/db/user.list
pour votre port et assurez vous que votre port soit ajouté à ce fichier au moment du commit. make fake
. Les bibliothèques ne devraient jamais être retirées. Les exécutables sont supprimés par défaut; ceci est gouverné par ${INSTALL_STRIP}
. ${INSTALL_PROGRAM}
honore cela automatiquement et est préférable à des retraits inconditionnels (par exemple, par une cible install-strip
ou en exécutant strip
depuis le Makefile
). Vous pouvez utiliser objdump --syms
pour déterminer si un binaire est retiré ou non. Les fichiers retirés n'ont pas de symboles dans la SYMBOL TABLE
. /etc/mtree
soit à jour. (La prochaine étape utilise les listes mtree pour supprimer les répertoires existants des les listes d'empaquetage générées). Souvenez-vous que (U)pdate
d'OpenBSD ne touche pas à /etc
… Pour mettre à jour automatiquement /etc
, sysmerge(8) peut aider. pkg/PLIST
. Après que l'installation avec make fake
soit complète, utilisez la commande de développeur make update-plist
, qui crée ou met à jour le fichier PLIST
dans le répertoire pkg
. Ce fichier est un candidat pour la liste d'empaquetage. PLIST
et vérifiez que tout a été installé et installé aux bons endroits. Tout ce qui n'a pas été installé peut être ajouté par une règle Makefile post-install
. Notez que les annotations PLIST sont documentées dans le manuel pkg_create(1). LIB_DEPENDS
ou RUN_DEPENDS
, exécutez make update-plist
pour les supprimer. make package
, testez l'installation du paquet résultant avec make install
, et testez sa suppression avec make uninstall
. Lors du traitement de paquets multiples, il peut être préférable d'utiliser directement pkg_add(1) et pkg_delete(1), en paramétrant PKG_PATH sur /usr/ports/packages/`arch -s`/all/
dans l'environnement. DEPENDS
, et rien d'autre. Vérifiez les noms, particulièrement à l'étape make configure
, pour les dépendances cachées (du genre qui existe ailleurs dans l'arborescence des ports et qui pourrait être détectée si l'utilisateur installe d'abord d'autres ports).make port-lib-depends-check
et ajoutez chaque annotation LIB_DEPENDS
ou WANTLIB
jusqu'à ce que cela fonctionne correctement. Il se peut que vous ayez besoin de lire les directives de mise à jour pour comprendre pourquoi c'est si important. NO_TEST=Yes
si le port n'a pas d'infrastructure de test. Si des dépendances sont requises pour exécuter les tests, mais pas pour construire le port, listez-les dans TEST_DEPENDS
. Veuillez noter : ne pas paramétrez NO_TEST
si le port possède un test de régression vide. make clean
. Parfois l'étape make fake
crée des fichiers dans le répertoire de compilation qui peuvent provoquer un échec. /usr/ports/infrastructure/bin/portcheck
dans le répertoire de votre port et traitez les problèmes qu'il trouve, le cas échéant. sizeof(int) != sizeof(long)
sur cette plate-forme. @newuser
ou @newgroup
dans les fichiers PLIST
, vérifiez qu'aucun utilisateur n'a été ajouté à /usr/ports/infrastructure/db/user.list
depuis que le port a été créé. cvs import
, plutôt que d'ajouter les nouveaux fichiers individuellement. Par exemple, pour importer un nouveau port lang/kaffe1
, faites d'abord une importation : $ cd /usr/ports/lang/kaffe1 $ cvs -ndcvs.openbsd.org:/cvs import ports/lang/kaffe1 username username_yyyymmdd
Où username
est votre nom de compte utilisateur, et yyyymmdd
est la date actuelle. Si cela réussit, alors vous pouvez supprimer l'option -n
pour importer vraiment. Votre éditeur sera invoqué pour que vous puissiez entrer un message de validation. Dans le message de commit, indiquez au moins ce que vous importez et quels développeurs ont donné leur accord. Assurez-vous que le chemin d'import soit correct ; il débute toujours par ports/
. Alternativement, vous pouvez utiliser ports/infrastructure/bin/portimport
pour importer de nouveaux ports (lisez le manuel pour les instructions d'utilisation).
Makefile
du répertoire parent, par ex., pour ports/lang/kaffe1
, ajoutez-le à ports/lang/Makefile
. Ne pas oubliez de diffuser tout changement fait à /usr/ports/infrastructure/db/user.list
. Supposons que vous avez réussi à construire le logiciel, à fournir les correctifs requis et que vous voulez terminer le portage.
Identifier les options
La première étape est habituellement d'identifier les options de compilation. Vous devrez souvent lire le journal de configuration, voir ce que votre port détecte automatiquement. Lisez les options du script configure. Lisez la documentation du port pour plus d'informations.
Faire en sorte que les options fonctionnent
Recompilez votre port avec différentes options. Installez les dépendances supplémentaires. Assurez-vous que votre port les détecte correctement. Ajouter les correctifs supplémentaires pour vous assurer de la compilation. Testez le résultat, et vérifiez que les choses supplémentaires fonctionnent.
Identifier les logiciels oubliés.
Certaines dépendances ne seront pas satisfaites car le logiciel manquant n'a pas encore été porté. Il est hautement recommandé de désactiver explicitement ces options. Ne pas faire cela provoque régulièrement des échecs de compilations groupées : une personne porte un nouveau logiciel et l'importe, et peu de temps après, d'anciens ports s'arrêtent de compiler parce qu'ils détectent la dépendance, essayent de l'utiliser, et sont en échec de compilation ou d'empaquetage.
Contrôler les dépendances d'exécution par rapport aux dépendances de génération
Mettez à jour votre liste d'empaquetage avec make update-plist
. Utilisez make port-lib-depends-check
pour voir de quelles bibliothèques a besoin votre logiciel (qui finira dans LIB_DEPENDS
ou WANTLIB
, habituellement). Identifiez les nombreux fichiers et binaires dans les dépendances qui doivent être présents pour que le port fonctionne.
À ce stade, vous devriez avoir une bonne compréhension de comment fonctionne votre port.
Ne vous souciez pas de certaines options. Cela n'a pas de sens de désactiver certaines choses si elles fonctionnent toujours, et si les dépendances sont assez petites. Prenez spécialement notes des licences sur les dépendances, spécifiquement à-propos des PERMIT*
. En règle générale, même si une dépendance est très petite, si elle affecte la licence du package résultant, vous devez y faire explicitement attention.
Considérant toutes les options possibles, vous devriez avoir un ensemble beaucoup plus petit d'options pour votre port, essentiellement en fonction des packages nécéssaires pour exécuter le logiciel. Dans l'immédiat, ne vous inquiétez pas des dépendances de compilation. Souvenez-vous que le système de ports OpenBSD est centré sur l'utilisateur final, que l'utilisateur final voudra installer des packages binaires, donc peu importe que vous ayez besoin d'une énorme quantité de logiciels pour construire votre port si ceux ci n'apparaissent pas comme des bibliothèques ou des dépendances d'exécution.
Maintenant, vous devriez avoir une très bonne idée de :
Dans le cas idéal, les options de compilation créeront simplement de nouveaux fichiers, avec de nouvelles dépendances, et n'affecteront pas d'autres choses. C'est un scenario assez courant pour les frameworks de plugins : vous ajoutez une librairie, vous obtenez un nouveau plugin. Ceci arrive assez souvent pour les applications centrales avec une interface graphique : l'application console est compilée chaque fois, et l'interface X11 apparaît en tant que binaire séparé.
Dans ce cas, essayez de paramétrer la variable MULTI_PACKAGES
pour lister les packages -sub, ajouter les COMMENTS
correspondants, et regarder votre empaquetage. Basiquement, MULTI_PACKAGES
affecte seulement l'empaquetage. Si vous avez MULTI_PACKAGES=-s1 -s2
, tout ce qui relève du package existera en deux variantes : COMMENT-s1
pour le premier package, COMMENT-s2
pour le second package, PLIST-s1
, PLIST-s2
, DESCR-s1
, DESCR-s2
. Vous avez besoin d'écrire COMMENT-s1
et COMMENT-s2
dans le Makefile
, de découper votre PLIST
en deux parties, et de créer DESCR-s1/DESCR-s2
. Vous avez aussi besoin de spécifier des PKGNAME
séparés pour tous les sous-paquets.
C'est une bonne idée de commencer le travail requis avec un framework minimal : copiez simplement la description et les commentaires existants, parce que vous avez besoin de triturer MULTI_PACKAGES
et d'autres choses, avant d'affiner cela.
Une fois que vous avez séparé les fichiers proprement, vous avez besoin de vérifier les dépendances : LIB_DEPENDS
, WANTLIB
, et RUN_DEPENDS
seront fractionnés pour chaque sous-paquet. C'est généralement le moment de vérifier que votre empaquetage multiple “fonctionne”, et que ces dépendances désagréables qui ne devraient pas s'imposer à l'utilisateur soient reléguées à un sous-paquet spécifique.
Si cela fonctionne, vous avez presque fini. Il suffit de choisir des noms raisonnables pour les différents paquets, et de remplir les commentaires et les descriptions. L'utilisateur final sera capable d'installer simplement le(s) package(s) désiré(s).
Mais, attendez. Qu'en est-il de la compilation ? Eh bien, avoir beaucoup de dépendances durant la compilation n'est pas un problème. La plupart des packages sont construits par l'équipe d'OpenBSD en utilisant des procédures de compilations spéciales (connues en tant que bulk builds) où un développeur compile simplement tous les packages possibles sur une machine dédiée (ou sur plusieurs, pour les architectures lentes). Puisque tout sera compilé, avoir de lourdes dépendances n'est pas un problème. Compiler la même chose plusieurs fois est un problème, c'est pourquoi MULTI_PACKAGES
est la meilleure manière de gérer les options (quand cela est possible) : une compilation, un ensemble de paquets à tester, une meilleure qualité par dessus tout…
Si vous souhaitez aider des personnes à compiler elles-mêmes des packages, vous pouvez considérer l'ajout de PSEUDO_FLAVORS
. Une pseudo-saveur est une manière de modifier une option (disons, désactiver l'interface graphique), ce qui est très similaire aux saveurs normales. Dans les faits, la grande différence est une différence fonctionnelle : une pseudo saveur ne devrait affecter seulement que l'ensemble de packages qu'elle a compilé, mais il ne lui est jamais permis de modifier le contenu de l'actuel package.
Par exemple, en considérant que vous avez séparé l'interface graphique dans un sous-paquet séparé (MULTI_PACKAGES=-core -x11
), vous devriez créer une pseudo saveur no_x11
qui évite de compiler le sous-package -x11. Le point crucial est que cette saveur N'affectera PAS le package -core de quelque manière que ce soit.
Vous finiriez avec un Makefile
qui ressemblerait à cela :
CATEGORIES = app COMMENT-core = foo core application COMMENT-x11 = foo graphical interface V = 1.0 DISTNAME = foo-$V PKGNAME-core = foo-core-$V PKGNAME-x11 = foo-x11-$V PSEUDO_FLAVORS = no_x11 FLAVOR ?= CONFIGURE_STYLE = gnu MULTI_PACKAGES = -core WANTLIB = c m crypto ssl WANTLIB-x11 = ${WANTLIB} X11 Xt RUN_DEPENDS-x11 = ${BASE_PKGPATH},-core .if ${FLAVOR:L:Mno_x11} CONFIGURE_ARGS += --disable-x11 .else MULTI_PACKAGES += -x11 .endif .include <bsd.port.mk>
Notez que vous n'avez qu'à écrire une toute petite section conditionnelle dans le Makefile
: le système ne se soucie pas du tout que vous définissiez des variables supplémentaires.
Les paramétrages MULTI_PACKAGES
étaient autrefois asymétriques, avec un sous-package -main et d'autres sous-packages, le sous-package -main était toujours construit, et éventuellement les sous-packages dépendants de lui. La situation actuelle est totalement symétrique : tout sous-package peut dépendre d'un autre. L'infrastructure a des dispositions spécifiquers pour éviter de boucler indéfiniment.
L'infrastructure accorde un soin particulier aux bibliothèques inter-dépendantes : elle peut détecter quel WANTLIB
vient de dépendances externes, et lequel vient d'inter-dépendances. Tandis que les bibliothèques externes LIB_DEPENDS
et WANTLIB
sont vérifiées au démarrage de la compilation, les LIB_DEPENDS
et WANTLIB
qui se référent à un des sous-packages en cours de compilation, seront seulement vérifiées au moment de l'empaquettage (et ainsi, ces packages peuvent être créés dans un ordre spécifique pour satisfaire l'inter-dépendance).
L'infrastructure fournit des variables spécifiques pour aider à écrire les inter-dépendances : BUILD_PKGPATH
contient le PKGPATH
utilisé durant la compilation des packages en question, prenant en compte les saveurs et pseudo-saveurs. Il est fortement recommandé d'utiliser cette variable au lieu de votre solution personnelle : ne pas respecter celà déclenchera souvent des reconstructions dans des situations de saveurs intéressantes. Par exemple :
... FLAVORS = a b FLAVOR ?= MULTI_PACKAGES = -p1 -p2 WANTLIB-p1 = foo LIB_DEPENDS-p1 = some/pkgpath,-p2 ...
Si vous continuez et compilez via un/quelconque/pkgpath avec FLAVOR=a
, alors créez le sous-paquet pour -p1
déclenchera une reconstruction avec FLAVOR=''
. Écrivez plutôt cela :
LIB_DEPENDS-p1 = ${BUILD_PKGPATH},-p2
Il y a aussi une variable BASE_PKGPATH
, qui ne prend pas en compte les pseudo-saveurs. Cette variable a une applicabilité limitée : elle correspond à une transition entre les anciens MULTI_PACKAGES
et les plus récents, où l'ancien sous-paquet principal n'avait pas de marqueur dans son chemin d'accès, et donc le paquet correspondant nécessite un chemin d'accès @pkg ${BASE_PKGPATH}
dans sa liste d’empaquetage. (En général, les pseudo-saveurs sont des informations de compilation, et ne devraient pas se retrouver dans les packages et les listes d'empaquetage).
Il y a certains cas où les options de configuration sont trop invasives, et vous devrez ajouter de vraies saveurs au Makefile
: ces saveurs commanderont certaines options de configuration, et habituellement des ajouts à de diverses dépendances. Notez que le nommage de paquets est souvent automatique : le PKGNAME
aura une extension construite par ajout des saveurs spécifiées à son nom. Ainsi, si :
PKGNAME = foo-1.0 FLAVORS = f1 f2 f3
et que vous construisez le port avec FLAVOR='f3 f1'
, alors FULLPKGNAME=foo-1.0-f1-f3
(FLAVORS
est utilisée pour réordonner les saveurs spécifiées d'une manière canonique).
Il y a parfois des situations mélangées, où certains packages dépendent de FLAVOR
, et d'autres non. Par exemple, certains ports incluent un large ensemble de documentations qui ne dépend pas de FLAVOR
, et quelques programmes actuels qui dépendent de FLAVOR
. Dans de tels cas, vous pouvez spécifier FULLPKGNAME
explicitement pour le sous-paquet de documentation. Quelque chose comme :
CATEGORIES = app COMMENT-core = foo application COMMENT-doc = foo documentation V = 1.0 DISTNAME = foo-1.0 PKGNAME-core = foo-$V FULLPKGNAME-doc = foo-doc-$V FLAVORS = crypto MULTI_PACKAGES = -core -doc WANTLIB-core = c m .if ${FLAVOR:L:Mcrypto} WANTLIB-core += ssl crypto CONFIGURE_ARGS += --enable-crypto .endif
Tel que mentionnée dans la documentation, tous les noms de packages ont la même structure : stem-version-flavor_extension
.
Par défaut, les packages avec la même souche, et les mises à jour vont chercher des candidats ayant la même souche. Le bon package sera celui venant de l'identique exact PKGPATH
, ou correspondant à l'annotation @pkgpath
dans la liste d'empaquetage.
Habituellement, MULTI_PACKAGES ne devraient pas être en conflit, puisqu'ils doivent avoir des noms différents (et l'infrastructure n'a aucun moyen de construire ces noms). D'un autre côté, les saveurs devraient être en conflit, puisqu'elles ont le même nom. L'information de saveur devrait être à la fin du nom de package, exceptée pour les pseudo-saveurs, ce qui ne change pas la manière dont un package est compilé.
En ce qui concerne les dépendances, par défaut, spécifier un PKGPATH
créera juste une dépendance stem-*
, ce qui signifie que tout paquet avec la bonne souche correspondra à la dépendance. Par défaut, toute saveur correspondra. Si seules des saveurs spécifiques sont désirées, vous devez les inclure dans votre spécification, ex., stem-*-flavor
. Si certaines saveurs ne sont pas recherchées, vous pouvez les supprimer de la correspondance des packages, ex., stem-*-!flavor
.
Depuis OpenBSD 4.9, demander au moins une certaine version de dépendance peut être directement adressé à PKGPATH
, ex., dir/foo>=2.0
.
Les outils des packages peuvent subir des mises à jours, ainsi les mainteneurs doivent faire attention à ce simple fait : les mises à jours ne sont pas instantanées. Même si un utilisateur passe juste d'une version à l'autre, chaque fois, qu'il exécute pkg_add -u
, le système remplacera chaque package par une nouvelle version, un paquet à la fois. Ainsi l'utilisateur exécutera un système mélangé, même si cela est juste pour quelques minutes.
Il y a fondamentalement deux modèles de mises à jours dont les mainteneurs doivent être au courant.
Notez qu'une partie du processus de mise à jour, en particulier les modifications macroscopiques pour les utilisateurs qui mettent à jour tous les six mois, n'est pas encore automatisée. Le mécanisme global de mise à jour est toujours en cours d'élaboration et pkg_add sera en mesure de faire face à d'autres problèmes à l'avenir. Pour l'instant, vous devriez vous concentrer sur le fait que le système fasse ses mises à jour à correctement, un port à la fois, et que la mise à jour d'un port tient compte des autres ports, en ce qui concerne les conflits et autres problèmes.
Une partie du travail doit être effectuée lors de la réalisation du port lui-même.
${WRKBUILD}/shared_libs.log
comme base de votre paramétrage SHARED_LIBS
. Cela aidera lors des mises à jour. PLIST_REPOSITORY
est paramétré par défaut et construira une base de données des listes d'empaquetage en tant que paquets construits sur votre système. C'est utile à fin de trouver les oublis de noms de paquets, et aussi pour vérifier les conflits avec d'anciens paquets. RUN_
et LIB_DEPENDS
peuvent être satisfaits par n'importe qu'elle version d'un package. N'insistez pas sur une version donnée sauf si vous le devez. Utilisez les versions minimales autant que possible. Les ports ont souvent besoin de mises à jour mineures sans nouvelle version en amont.
HOMEPAGE
, MAINTAINER
ou de description, de chemins ou de drapeaux de compilation. Si la version en ammont n'a pas changé, la modification du nom du paquet se fait en incrémentant REVISION
si présent, sinon en ajoutant REVISION = 0
vers le haut du Makefile.EPOCH
pour vous assurer que pkg_add(1) voit le paquet comme un paquet plus récent. Cela ajoutera v${EPOCH}
à FULLPKGNAME
pour former un nom du package conforme aux spécifications de packages-specs(7).Une partie du travail aura lieu avant la mise à jour elle-même.
make patch
pour avoir une copie initiale du port avant la mise à jour.Et, ensuite la mise à jour.
Makefile
du port pour récupérer la nouvelle version, exécutez make makesum
et make patch
comme base de départ. shared_libs.log
pour vérifier ce que les auteurs du logiciels ont fait comme changements significatifs. Notez bien que cela ne suffit pas. De nombreux auteurs de logiciel ne comprennent pas réellement les problèmes de bibliothèques partagées. Vous devez lire le diff complet entre l'ancienne et la nouvelle version, et incrémenter les versions de librairies en fonction. En cas de doute, incrémenter la version.pkg_add -u
, assurez-vous qu'elles soient visibles. Quand votre politique d'empaquetage change, documentez-la dans la description du package. Par exemple, si vous déplacez la documentation dans un package séparé pour des contraintes d'espace, la description du package principal devra mentionner que la documentation est maintenant disponible dans un package séparé. Quand une mise à jour du port est prête, mettez-la dans CVS. Si vous n'avez pas de compte CVS, alors vous devrez trouver un développeur pour faire cela pour vous (demandez sur ports@openbsd.org).
cvs add
pour ajouter les nouveaux fichiers.cvs rm
pour supprimer les fichiers qui n'ont plus besoin d'y être (ex. les patches ayant été acceptés en amont). cvs -n up -d
. Les nouveaux fichiers devraient être marqués A
, les fichiers effacés devraient être marqués D
et les fichiers changés devraient être marqués M
. Cherchez les fichiers marqués ?
- souhaitiez-vous les cvs add
? cvs commit
. Lorsque vous invoquez cvs commit
, vous pouvez soit lister les fichiers individuellement, ou si vous ne fournissez aucun nom de fichier, CVS les validera récursivement (faites attention avec cette fonctionnalité). Il vous sera demandé d'entrer un message de validation, dans lequel vous devrez indiquer quel port est mis à jour, et qui a fourni un OK. /usr/local/etc/rc.d
. /usr/local
est souvent partagé entre plusieurs machines, grâce à NFS. Pour cette raison, les fichiers de configuration qui sont spécifiques à une machine donnée ne peuvent être enregistrés sous /usr/local
. /etc
est le dépôt central pour les fichiers de configuration par machine. De plus, la politique d'OpenBSD est de ne jamais mettre à jour les fichiers sous /etc
automatiquement. Les ports qui ont besoin d'une configuration de démarrage spécifique doivent avertir l'administrateur ce qu'il doit faire au lieu d'installer aveuglément des fichiers. -lcrypt
, -ldl
, ou -lrt
. Les fonctions fournies par ces bibliothèques sont une partie de libc
. La fonction crypt()
ne supporte pas DES, seulement bcrypt. /usr/ports/infrastructure/db/user.list
pour les détails. $OpenBSD$
au Makefile. Le nom du compte, le numéro de version, etc, sera rempli automatiquement par CVS durant le commit, vous n'avez pas besoin de les ajouter dans une mise à jour. * Le but est d'obtenir que toutes les applications portées supportent OpenBSD. Pour atteindre ce but, transmettez les correctifs pour le fonctionnement sous OpenBSD au mainteneur de l'application. (Si vous n'êtes pas le mainteneur du port, vérifiez avec en premier. Il y a de nombreuses raisons pour lesquelles cela n'a pas été fait délibéremment).
Il y a de nombreux problèmes de sécurité à prendre en compte. Si vous n'êtes pas absolument sûr de ce que vous faites, veuillez demander de l'aide sur la liste de diffusion des ports.
strcat/strcpy/strcmp/sprintf
. En général, sprintf
doit être remplacé par snprintf
. /tmp
par des liens symboliques vers des fichiers plus stratégiques, tels que /etc/master.passwd
. fopen
et freopen
créent un nouveau fichier ou ouvrent un fichier existant pour écrire. Un attaquant peut créer un lien symbolique depuis /etc/master.passwd
vers /tmp/addrpool_dump
. À l'instant où vous l'ouvrez, votre fichier de mot de passe est foutu. Oui, même avec un unlink
juste avant. Vous réduisez seulement la fenêtre d'opportunité. Utilisez open
avec O_CREAT|O_EXCL
et fdopen
à la place. mktemp
. Respecter les avertissements du linker bsd concernant ses utilisations. Celles-ci doivent être fixées. Ce n'est pas aussi simple que s/mktemp/mkstemp/g
. Reférez-vous à mktemp(3) pour plus d'informations. Des exemples d'usages corrects de mkstemp
incluent le code source de ed
ou mail
. Un exemple rare de code qui utilise mktemp
correctement peut être trouvé dans le port rsync
. startx
. En tant que programme setuid, vous pouvez lancer startx avec n'importe quel fichier en tant que script. Si le fichier n'était pas un script shell valide, un message d'erreur de syntaxe suivrait, ainsi que la première ligne du fichier incriminé, sans autre vérification d'autorisation. Assez pratique pour attraper la première ligne d'un fichier shadow passwd, étant donné que ceux-ci commencent souvent par l'entrée root. N'ouvrez pas votre fichier, pour ensuite faire un fstat
sur le descripteur ouvert pour vérifier si vous auriez dû pouvoir l'ouvrir (ou l'attaquant jouera avec /dev/rst0
et rembobinera votre enregistrement sur bande). – ouvrez le avec l'ensemble correct uid/gid/grouplist. popen
et system
. Utilisez fork
, pipe
et execve
à la place. /dev/fd/0
.xkobo
comme exemple d'un tel changement. PATH
(ne jamais utiliser system
avec un nom non qualifié, éviter execvp
), mais aussi des éléments plus subtils comme votre locale, fuseau horaire, termcap, etc. Soyez conscient de la transitivité : même si vous prenez toutes les précautions nécessaires, les programmes que vous appelez directement ne le feront pas nécessairement. Ne jamais utiliser system
dans des programmes privilégiés, aménagez votre propre ligne de commande, un environnement contrôlé, et appelez directement execve
. La page de manuel perlsec
est un bon tutoriel concernant de tels problèmes. issetugid
d'OpenBSD résout ce problème, du point de vue de l'auteur de la bibliothèque. N'essayez pas de porter des bibliothèques sauf si vous comprenez bien ce problème. arc4random
est utilisée à la place. Si le comportement déterministe (c-à-d, répétable) doit être préservé, utilisez les extensions d'OpenBSD : srand_deterministic
, srandom_deterministic
, srand48_deterministic
, seed48_deterministic
et lcong48_deterministic
. __OpenBSD__
devrait être utilisé avec parcimonie, voir pas du tout. Les tournures de ce type #if defined(__NetBSD__) || defined(__FreeBSD__)
sont souvent inappropriées. N'ajoutez pas aveuglément __OpenBSD__
. Au lieu de cela, essayez de comprendre ce qui se passe, et quelle fonctionnalité est réellement nécessaire. Les pages de manuel sont souvent utiles, car elles incluent des commentaires historiques, indiquant quand une fonctionnalité particulière a été incorporée dans BSD. Vérifiez la valeur numérique de BSD
par rapport aux versions connues est souvent la bonne manière. Lisez le guide pkgsrc de NetBSD pour plus d'informations.
BSD
est une mauvaise idée. Essayez d'inclure sys/param.h
. Cela ne définit pas seulement BSD
, cela donne aussi une valeur appropriée. Le bon fragment de code devrait ressembler à ceci : #if (defined(__unix__) || defined(unix)) && !defined(USG) #include <sys/param.h> #endif
tcgetattr
fonctionne que de tester si vous utilisez BSD 4.3 ou une version ultérieure, ou SystemVR4. Ce genre de tests ne font qu'embrouiller le problème. La bonne manière de faire cela est, par exemple, de tester pour un système particulier, définissez une série de HAVE_TCGETATTR
, puis passez au système suivant. Cette technique sépare les fonctionnalités de tests selon les OS spécifiques. En toute hâte, un autre porteur peut simplement ajouter l'ensemble des définitions -DHAVE_XXX
dans le Makefile. Un autre peut aussi écrire ou ajouter un script configure pour surveiller si cette fonctionnalité est requise puis l'ajouter automatiquement. Comme exemple à ne pas suivre, jetez un œil aux sources de nethack 3.2.2 : il considère acquises beaucoup de choses selon le type du système. La plupart de ces hypothèses sont obsolètes et ne reflètent plus la réalité : les fonctions POSIX sont plus utiles que ce qui différencie la vieille BSD de SystemV, au point que certaines fonctions bsd traditionnelles ne sont plus supportées que par les bibliothèques de compatibilité. #define POSIX_C_SOURCE
à travers tout le projet, et non pas quand vous en avez envie. unistd.h
, fcntl.h
ou termios.h
. La page de manuel indique fréquemment où ces prototypes peuvent être trouvés. Vous pourriez avoir besoin d'une autre série de macros HAVE_XXX
pour obtenir le bon fichier. Ne vous inquiétez pas d'inclure deux fois le même fichier : les fichiers à inclure ont des gardes qui empêchent toutes sortes de drame. Si un système mal conçu a besoin que vous écriviez le prototype, ne l'imposez pas à tous les autres systèmes. Les prototypes faits-maison casseront parce qu'ils peuvent utiliser des types équivalents sur votre système, mais ne sont pas portables avec d'autres systèmes (unsigned long
au lieu de size_t
), ou traiteront un status const
de la mauvaise manière. De plus, certains compilateurs, comme le gcc d'OpenBSD, sont capables de faire un meilleur travail avec des fonctions très fréquentes comme strlen
si vous incluez le bon fichier d'entête. implicit declaration of function foo()
indique qu'un prototype de fonction est manquant. Cela signifie que le compilateur supposera que le type de retour soit un entier. Lorsque la fonction renvoie un pointeur, sur les plates-formes 64 bits il est tronqué, ce qui provoque généralement un erreur de segmentation. /* prototype part */ #ifdef USE_OWN_GCVT char *foo_gcvt(double number, size_t ndigit, char *buf); #else /* include correct file */ #include <stdlib.h> /* use system function */ #define foo_gcvt gcvt #endif /* definition part */ #ifdef USE_OWN_GCVT char *foo_gcvt(double number, size_t ndigit, char *buf) { /* proper definition */ } /* typical use */ s = foo_gcvt(n, 15, b);
bsd.port.mk
paramètrent le chemin de l'installeur. Spécifiquement, elles font en sorte que /usr/bin
et /bin
soient parcourus avant /usr/local/bin
et /usr/X11R6/bin
. bsd.port.mk
, car les personnes sont supposées mettre à jour en entier leur arborescence des ports, ce qui inclut bsd.port.mk
.update-plist
pour générer et mettre à jour les listes d'empaquetage au lieu de faire les choses manuellement. Vous pouvez commenter les lignes non désirées avec @comment
. Le fichier update-plist
peut détecter la plupart des types de fichier et copier correctement la plupart des annotations supplémentaires. Ce n'est pas infaillible ; revoyez les changements faits. Vérifiez qu'ils donnent du sens, et vérifiez que tout fichier d'exemple de configuration doit être suivi d'annotations @sample
.curses.h/libcurses/libtermlib
sont les “nouvelles curses”. Changez : ncurses.h ==> curses.h
Les “anciennes (BSD) curses” sont disponible en définissant _USE_OLD_CURSES_
avant d'inclure curses.h
(habituellement dans Makefile
) et avant de lier avec -locurses
.
sgtty
BSD vers la nouvelle famille POSIX tcgetattr
. Évitez l'ancien style dans le nouveau code. Certains codes peuvent définir tcgetattr
comme étant synonyme de l'ancien sgtty
, mais c'est au mieux une mesure stopgap
sur OpenBSD. Le code source de xterm
est un très bon exemple de ce qu'il ne faut pas faire. Essayez de gérer la fonctionnalité de votre système correctement : il vous faut un type qui retienne l'état de votre terminal (éventuellement typedef), il vous faut une fonction qui extrait l'état actuel, et une fonction qui définit le nouvel état. Les fonctions qui modifient cet état sont plus difficiles, car elles ont tendance à varier selon le système. De même, n'oubliez pas que vous avez à gérer des cas où vous ne serez pas connecté à un terminal, et que vous avez besoin de capturer les signaux : pas seulement la terminaison, mais aussi l'arrière plan (SIGTSTP
). Vous devriez toujours garder le terminal dans un état sain. Faites vos tests sous un ancien shell, tel que sh, qui ne réinitialisera pas le terminal à la sortie du programme. sigaction
pour vous assurer des sémantiques spécifiques, ainsi que des autres appels mentionnés dans la page de manuel correspondante.
Cette page est la traduction officieuse de la page “Ports - Porting Guide” de la FAQ officielle d'OpenBSD.
En cas de doute, merci de vous y référer !
Si vous voulez participer à l'effort de traduction, merci de lire ce topic.
Contribut(rice|eur)s :