Informations sur le portage OpenBSD

Différences importantes avec les autres projets BSD

NetBSD emploie le terme ports dans les cas dépendants de l'architecture. Leur structure de ports est plutôt appelée packages.

Support additionnel

build/resolve-lib

invoqué via make lib-depends-check, pour vérifier les dépendances de bibliothèques dynamiques.

build/update-patches

invoqué via make update-patches, qui devrait toujours être utilisé pour regénérer les patches.

install/make-plist

invoqué via make update-plist. Il s'inquiète de la plupart des points importants influant sur la création des listes de paquetage. Les listes de paquetage OpenBSD sont significativement différentes de celles des autres projets BSD, en partie car les outils de paquetage ont été complètement réécris.

Problèmes d'infrastructure Génériques

Le make d'OpenBSD supporte ${VAR:U} et ${VAR:L} pour transformer la valeur d'une variable dans une casse majuscule ou minuscule. De la même manière, make tests devrait être codé d'une manière insensible à la casse, par exemple,

        .if ${NEED_XXX:L} == "yes"
        do stuff if yes
        .else
        do other stuff
        .endif

En théorie, toutes les variables booléennes reconnues par bsd.port.mk devraient toujours être définies, les codes comme defined(USE_FOO) ne seraient ainsi pas nécessaires, et ${USE_FOO:L} != "no" devrait fonctionner.

Le principal fichier bsd.port.mk a été lourdement profilé et corrigé. En particulier, il supporte des processus make parallèles. La fonctionnalité scripts/{pre,do,post}-* a été perdue dans le processus. Pour remplacer cette fonctionnalité, invoquez le script manuellement, depuis le Makefile.

Utilisation correcte de make

Notez que, si vous invoquez make avec make VAR=value, l'assignation redéfinira toute valeur VAR pouvant provenir du Makefile. Ainsi, de nombreux patches ne sont pas nécessaires, il est plus avantageux de fixer correctement MAKE_FLAGS, pour diminuer le fardeau de la maintenance.

Récupération des sources

Il y a deux sortes d'archives sources : DISTFILES et PATCHFILES. OpenBSD les traite d'une manière identique, et les recherche par défaut depuis MASTER_SITES. Il n'y a ni PATCH_SITES ni PATCH_SITES_SUBDIR.

Si tous les fichiers récupérés ne viennent pas du même ensemble de sites, OpenBSD autorise l'extension filename:0 à filename:9, auquel cas MASTER_SITES0 à MASTER_SITES9 seront utilisés pour récupérer les fichiers.

Certaines architectures pourraient avoir besoin d'archives de distribution spécifiques. Par le passé, ceci a causé des problèmes quand des archives de distribution sur les mirroirs étaient concernées. OpenBSD supporte un troisième ensemble de fichiers : SUPDISTFILES. Ceux- ci seront seulement utilisés pour la création de sommes de contrôle et de contenus liés aux mirroirs. Notez que SUPDISTFILES pourrait chevaucher les DISTFILES ou PATCHFILES. Par exemple,

        DISTFILES=foo-1.0.tgz
        .if ${ARCH} == "i386"
        DISTFILES+=foo-i386.tgz
        .elif ${ARCHI} == "sparc"
        DISTFILES+=foo-sparc.tgz
        .endif
        SUPDISTFILES=foo-i386.tgz foo-sparc.tgz

L'infrastructure WRKDIR

Nous ne voulons pas des ports qui utilisent NO_WRKDIR. Tous les ports OpenBSD doivent avoir un répertoire de travail. Les détails de nommage de ces répertoires de travail ne devraient pas être le soucis du porteur. Si vous avez besoin de trouver un tel nom, demandez au Makefile : cd that_ports_dir && make show=WRKDIR devrait vous donner une idée du WRKDIR ce ce port.

La raison principale derrière cette interdiction est que le bsd.port.mk d'OpenBSD agit comme un vrai Makefile, avec des dépendances. L'étape fetch dépend des archives de distribution et des fichiers de patch, toutes les autres étapes dépendent de vrais fichiers peuplant le répertoire de travail (cookies), ne pouvant exister sans répertoire de travail.

EXTRACT_ONLY=

et faites l'extraction dans post-extract.

WRKDIR

Le répertoire de travail des ports, ou sont mis les cookies de celui- ci.

WRKDIST

Le sous-répertoire de WRKDIR ou les ports sont actuellement décompressés. C'est aussi le répertoire de base pour les patchs. Les autres BSD ne font actuellement pas la distinction WRKDIST/WRKSRC et ont seulement WRKSRC.

WRKSRC

Répertoire sous-jacent de WRKDIST ou les sources actuelles se trouvent.

WRKBUILD

Répertoire sous-jacent de WRKDIR ou la configuration et la construction du port se réalisera. Les autres BSD ne font pas la distinction WRKBUILD/WRKSRC. Les programmes basés sur autoconf (la plus grande partie) peuvent habituellement fixer SEPARATE_BUILD pour permettre la construction du port dans un répertoire WRKBUILD distinct de WRKSRC.

WRKCONF

Sous-répertoire de WRKDIR d'ou les scripts configure devraient être lancés. Il est par défaut WRKBUILD, qui est correct 99% du temps.

WRKINST

Répertoire ou le port sera installé avant la mise en paquetage (consultez la section Simulation des ports ci-dessous).

Notez que NO_WRKSUBDIR a été retiré : l'équivalent peut être accomplit en fixant à la place WRKDIST=$(WRKDIR).

Simulation des ports

Introduction

Lorsque la construction du port est terminée, les autres BSD traitent ensuite de l'installation du port, puis construisent un paquetage grâce au port installé. OpenBSD utilise à la place la simulation d'installation.

• Un port OpenBSD est configuré et construit normalement (par exemple, installé dans PREFIX, habituellement /usr/local).
• Mais il est possible de l'installer partout, normalement dans WRKINST, qui est habituellement un répertoire sous-jacent de WRKDIR.
• Ensuite l'installation fictive est mise en paquetage, en utilisant l'option -B de pkg_create.
• Enfin, le paquetage résultant peut être installé, en utilisant pkg_add.

Avantages

• Pour un constructeur de paquetage, ceci signifie que la plupart des ports n'ont pas à être installés, ce qui évite un grand nombre de compromis et d'effets généraux néfastes provoqués par des ports mal installés. Ceci permet aussi la construction de plusieurs paquetages conflictuels sur la même machine. Enfin, ceci permet de construire un nouvel ensemble de paquetages non testés sans éclabousser une installation correcte.
• Pour un développeur de ports, ceci simplifie agréablement la recherche de problèmes dans les listes de paquetage, puisque le lieu de l'installation fictive est vide avant que le port soit installé. Ainsi, si un port installe trop de fichiers, il n'est désormais plus nécessaire de personnaliser l'installation du port : ce n'est pas suffisant pour enregistrer les fichiers supplémentaires dans la liste des paquetages.
• Pour l'utilisateur final, ceci améliore la qualité des paquetages : à condition que le port final soit installé en utilisant pkg_add, l'utilisateur final obtient exactement le même logiciel que celui qui fut préparé sur la machine du porteur.

Comment le faire

Les cibles invoquées pour make fake sont les cibles habituelles d'installation, excepté sur quelques points de différence :

• FAKE_FLAGS est utilisé au lieu de MAKE_FLAGS. Par défaut, FAKE_FLAGS fixe DESTDIR=${WRKINST}.
• FAKE_TARGET est utilisé au lieu de INSTALL_TARGET.
• Les fragments {pre,do,post}-install sont invoqués avec TRUEPREFIX fixé à $(PREFIX), PREFIX fixé à $(WRKINST)$(PREFIX), et DESTDIR fixé à $(WRKINST).

Les ports utilisant imake devraient fonctionner ainsi, puisque les fragments imake sont configurés pour utiliser DESTDIR. De même, les GNU configure récents de devrait pas nécessiter de changement.

Une autre bonne technique est une astuce d'attache tardive : configurez les ports pour utiliser un préfixe $(DESTDIR)/usr/local, le Makefile résultant aura ainsi

prefix=$(DESTDIR)/usr/local

fixé. Quand le port est construit, puisque DESTDIR n'est pas fixée, /usr/local est utilisé, et l'installation fictive mettra tous les fichiers dans WRKINST/usr/local (par exemple, pour les configure GNU, utilisez CONFIGURE_STYLE= gnu dest).

Pièges

• Certains ports sont contradictoires dans leur traitement de DESTDIR : la plupart des ports préfèrent que DESTDIR soit fixée, mais pas un ou deux contrevenants. Corrigez le problème.
• Soyez attentifs à distinguer l'emplacement actuel ou le port est installé, et l'emplacement enregistré dans les fichiers de configuration du paquetage. Ceci est très facile à outrepasser, mais facile à corriger en utilisant TRUEPREFIX.
• Les liens symboliques absolus nécessitent toujours une personnalisation. Heureusement, bsd.port.mk notifiera les problèmes de ce genre.
• Quelques ports ne veulent pas laisser $(DESTDIR) seule à l'étape de configuration. Un fragment post-configure qui peaufine tous les Makefiles pour ajouter DESTDIR est nécessaire.
• Très rarement, un port résistera à tous les essais raisonnables pour faire un FAKE. Une approche par force brute devrait fonctionner : utilisez pre-fake pour lier ou copier tout ce que le port veut trouver dans WRKINST, et passez à l'installation dans le chroot.

Outils de Packaging

Les outils de paquetage connaissent quelques types de fichiers, et peuvent faire un grand nombre de choses automatiquement : dans la plupart des cas, les scripts de commande @exec ou INSTALL ne sont pas nécessaires.
Notez que tous les scripts non nécessaires devraient être bannis, car ils posent des problèmes de stabilité. Il est plus facile de deboguer une infrastructure simple de paquetage que de modifier des centaines de scripts afin de gérer de nouveaux problèmes.
Par exemple :

• @exec ldconfig n'est pas nécessaire, car les bibliothèques partagées annotées avec @lib libfoo.so.1.0 et ldconfig ne sont lancées que quand celà est utile, et gèrent les chroot correctement.
• @exec install-info n'est pas nécessaire, car les fichiers de documentation sont annotés de @info file.info. Ceci prend également en compte les fichiers d'info multiples, et enlève le besoin de makeinfo --no-split .
• les fonts sont intégrées automatiquement grâce à @font et @fontdir.
• Les nouveaux utilisateurs et groupes sont gérés par @newuser et @newgroup plutôt que par les scripts d'installation. Ils sont créés assez tôt afin que l'extraction du paquetage puisse les utiliser.
• Les fichiers de configuration sont gérés via @sample plutôt que par les scripts d'installation.

Référez vous à pkg_create(1) pur plus de détails. Dans la plupart des cas, make update-plist écrira une très bonne approximation de la packing-list complète, et gèreront les améliorations d'une version à l'autre.

Saveurs

Les options ont été regroupées en saveurs, la construction des paquetages peut ainsi être conforme. Un port avec des options devrait fixer FLAVORS avec la liste des options qui ont un sens pour ce port (par exemple, FLAVORS=foo bar zoinx), et utiliser ensuite FLAVOR pour tester quelles options sont actuellement sélectionnées (par exemple, FLAVOR=zoinx foo). bsd.port.mk fournit un support :

• Le PKGNAME est personnalisé pour inclure des options séparées par des "-" (par exemple, package-foo-zoinx).
• Le WRKDIR est personnalisé, des saveurs distinctes peuvent ainsi être construites sans collision.
• Les constructions de la forme %%flavor%% déclencheront la saveur PFRAG. La construction %%SHARED%% déclenchera l'inclusion de PFRAG.shared.
• bsd.port.subdir.mk comprend l'extension SUBDIR=directory,opt1,opt2 pour spécifier la construction du port dans le répertoire avec FLAVOR=opt1 opt2.

Rechercher si une saveur donnée a été sélectionnée est aussi simple que :

.if ${FLAVOR:L:Mzoinx}