OBSD4* : wiki

Version de traduction basée sur la 6.2 officielle


Ports - Différences avec les Autres Projets BSD

Support Supplémentaire

L'infrastructure de portage comprend de nombreux scripts sous infrastructure/bin qui facilite la création de nouveaux ports :

check-lib-depends
invoqué par make lib-depends-check pour vérifier les dépendances des bibliothèques partagées.

update-patches
invoqué par make update-patches, qui devrait toujours être utilisé pour régénérer les correctifs.

make-plist
invoqué par make update-plist. Ceci prend en charge la plupart des points les plus fins de l'élaboration précise des listes d'empaquetage. Les listes d'empaquetage d'OpenBSD sont significativement différentes de celles des autres projets BSD, en partie du fait que les outils package ont été complétement ré-écrits.

Vérifiez le répertoire infrastructure/bin pour les scripts les plus utiles. La plupart sont documentés sous infrastructure/man.

Problèmes génériques d'infrastructure

La commande make(1) d'OpenBSD supporte ${VAR:U} et ${VAR:L} pour transformer la valeur d'une variable en majuscule ou minuscule. En conséquence, les tests make devraient être codés de manière indépendemment à 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, ainsi le code defined(USE_FOO) ne devrait pas être nécessaire, et ${USE_FOO:L} != “no” devrait fonctionner.

Le fichier principal bsd.port.mk a été fortement rationalisé et corrigé. En particulier, il est prêt pour la fabrication en parallèle. La fonctionnalité scripts/{pre,do,post}-* a été perdue dans le processus. Pour remplacer cette fonctionnalité, invoquez le script manuellement depuis le Makefile.

Utiliser make proprement

Notez que si vous invoquez make tel que make VAR=value, l'affectation surchargera la valeur que VAR peut obtenir du Makefile. Ce qui signifie que de nombreux correctifs Makefile ne sont pas nécessaires. Il est préférable de paramétrer correctement MAKE_FLAGS, ce qui diminue la charge de maintenance.

Récupérer les sources

Il y a deux types d'archives sources : DISTFILES et PATCHFILES. OpenBSD les traite de manière uniforme et récupère l'ensemble depuis MASTER_SITES par défaut. Il n'y a pas de PATCH_SITES ou de PATCH_SITES_SUBDIR.

Si tous les fichiers à récupérer ne proviennent pas du même ensemble de sites, OpenBSD autorise l'extension filename:0 à filename:9, dans ce cas il utilisera MASTER_SITES0 à MASTER_SITES9 pour récupérer le fichier.

Certaines architectures peuvent avoir besoin de distfiles spécifiques. Dans le passé, cela posait des problèmes où les distfiles répliqués étaient concernés. OpenBSD supporte un troisième jeu de fichiers : SUPDISTFILES. Ceux-ci sont à considérer seulement pour créer les sommes de contrôle et dans le but de miroir. Notez que SUPDISTFILES peut se superposer avec DISTFILES ou PATCHFILES. Par exemple :

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

L'infrastructure ''WRKDIR''

Nous ne voulons pas les ports qui utilisent NO_WRKDIR. Tous les ports OpenBSD doivent disposer d'un répertoire de travail. Nommer les détails de ces répertoires de travail ne devrait pas être la préoccupation du porteur. Si vous avez besoin de trouver un tel nom, demandez à Makefile :

  $ cd that_ports_dir && make show=WRKDIR

Cela donnera l'idée à ce port de WRKDIR.

La raison principale derrière cette interdiction est que bsd.port.mk d'OpenBSD agit comme un réel Makefile, avec des dépendances. Le phase fetch dépend des distfiles et patchfiles, et toutes les autres étapes dépendent de fichiers réels résidant sur le répertoire de travail (cookies), donc ils ne peuvent exister sans un répertoire de travail.

Si l'extraction DISTFILES est spéciale, paramétrez

EXTRACT_ONLY= 

et faites l'extraction dans post-extract.

WRKDIR
Le répertoire de travail du port, où sont déposés ses propres cookies.

WRKDIST
Sous-répertoire de WRKDIR où le port se décompresse réellement. C'est aussi le répertoire de base pour les correctifs. Actuellement les autres BSD n'ont pas la distinction WRKDIST/WRKSRC et ont uniquement WRKSRC.

WRKSRC
Sous-répertoire de WRKDIR où réside la source actuelle.

WRKBUILD
Sous-répertoire de WRKDIR où le port configure et construit. Les autres BSD n'ont pas la distinction WRKBUILD/WRKSRC. Les programmes basés sur un autoconf (essentiellement) peuvent généralement définir SEPARATE_BUILD pour laisser la construction du port dans un WRKBUILD distinct de WRKSRC.

WRKCONF
Sous-répertoire de WRKDIR où les scripts configure devraient être exécutés. Par défaut WRKBUILD, ce qui est correct 99 % du temps.

WRKINST
Répertoire où le port sera installé avant d'être empaqueté (voir ci-dessous “Simuler les ports”).

Notez que NO_WRKSUBDIR a été supprimé : sa fonctionnalité peut être obtenue en définissant WRKDIST=$(WRKDIR) à la place.

Simulation d'installation d'un port

Introduction

Après qu'une construction soit complète, les autres BSD procèdent à l'installation du port, ils construisent alors un package depuis le port installé. OpenBSD utilise une simulation d'installation à la place.

  • Un port OpenBSD est configuré et construit normalement (ex., pour installer sous PREFIX, généralement /usr/local).
  • Mais il est indiqué de l'installer ailleurs, à savoir WRKINST, qui est habituellement un sous-répertoire de WRKDIR.
  • Ensuite la simulation d'installation est empaquetée, en utilisant l'option -B de pkg_create.
  • Finalement, le package résultant peut être installé, en utilisant pkg_add.

Les avantages

  • Pour le constructeur d'un paquet, cela signifie que la plupart des ports n'ont pas à être installés actuellement, ce qui supprime un grand nombre de potentiels compromis et des désagréments généraux depuis des ports mal installés. Cela permet également de construire plusieurs paquets en conflit sur la même machine. Finalement, cela permet de construire un nouvel ensemble de paquets non testés sans perturber une installation correcte.
  • Pour l'auteur d'un port, cela simplifie grandement la tâche de trouver les problèmes dans la liste de paquetage, puisque l'espace de simulation d'installation est vidé avant que le port ne soit installé. De même, si un port installe trop de fichiers, il n'est plus nécessaire d'ajuster l'installation du port : il suffit de ne pas enregistrer les fichiers étrangers dans la liste de paquetage.
  • Pour les utilisateurs finaux, cela améliore la qualité des paquets : puisque le port final est installé en utilisant pkg_add, l'utilisateur a exactement le même logiciel qui a été préparé par le porteur.

Comment faire cela

Les cibles invoquées pour make fake sont les cibles d'installation habituelles, à l'exception de quelques différences :

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

Les ports utilisant imake devraient fonctionner tels quels, depuis que les fragments imake sont configurés pour utiliser DESTDIR. De la même manière, le récent port de GNU configure ne devrait pas avoir besoin de changement.

Une autre bonne technique est une astuce de “liaison tardive” : configurer les ports pour utiliser un préfixe de $(DESTDIR)/usr/local, ainsi le Makefile résultant a le paramètre suivant :

prefix=$(DESTDIR)/usr/local

Lorsque le port est construit, puisque DESTDIR n'a pas de paramètre, /usr/local est utilisé. La simulation d'installation déposera chaque chose dans ${WRKINST}/usr/local (ex., pour GNU configure, utilisez CONFIGURE_STYLE= gnu dest).

Pièges

  • Certains ports sont inconsistants dans le traitement de DESTDIR : la plupart des ports fonctionnent bien avec le paramètre DESTDIR, sauf un ou deux récalcitrant. Éliminez le problème.
  • Faites bien attention à distinguer entre l'emplacement actuel où est installé le port, et l'emplacement enregistré dans les fichiers de configuration du package. C'est très facile à ignorer, mais facile à corriger en utilisant TRUEPREFIX.
  • Les liens symboliques absolus doivent toujours être ajustés. Heureusement, bsd.port.mk avertira des problèmes dans ce domaine.
  • Quelques ports ne veulent pas laisser $(DESTDIR) seul à l'étape de configuration. Un fragment post-configure, qui ajuste tous les Makefiles pour ajouter le DESTDIR, est nécessaire.
  • Très rarement, un port résistera à toutes les tentatives raisonnables d'utiliser FAKE. Une approche brutale devrait fonctionner : utiliser pre-fake pour lier ou copier tout ce que le port souhaite trouver à l'endroit du WRKINST, puis effectuer l'installation sous chroot.

Les outils d'empaquetage

Les outils d'empaquetage connaissent un certain nombre de types de fichiers et peuvent faire beaucoup de choses automatiquement : dans la plupart des cas, les commandes @exec ou les scripts INSTALL ne sont pas nécessaires.

Notez que tous les scripts non nécessaires devraient être bannis, car ils ont des problèmes d'évolutivité. Il est plus facile de déboguer une unique infrastructure de packages que de modifier des centaines de scripts qui posent de nouveaux problèmes. Par exemple :

  • @exec ldconfig n'est pas nécessaire, car les bibliothèques partagées sont annotées avec @lib libfoo.so.1.0 et ldconfig qui fonctionne seulement au besoin, et gère chroot élégamment.
  • @exec install-info n'est pas nécessaire, car les fichiers de documentation info sont annotés avec @info file.info. Cela prend également en charge des multiples fichiers info, et supprime le besoin de makeinfo –no-split.
  • les polices sont intégrées automatiquement grâce à @font et @fontdir.
  • Les nouveaux utilisateurs et groupes sont gérés avec @newuser et @newgroup au lieu des scripts d'installation. Ils sont aussi créés assez tôt pour que l'extraction d'un paquet supplémentaire puisse les utiliser plus tard.
  • Les fichiers de configuration sont gérés par @sample au lieu des scripts d'installation.

Référez-vous à pkg_create(1) pour plus de détails. Dans la plupart des cas, make update-plist écrira une très bonne approximation de la liste de paquetage complète, et reportera les ajustements faits à la main d'une version à la suivante.

Saveurs

Les options ont été rationalisées en tant que saveurs, de sorte que la construction du paquet peut être cohérente. Un port avec des options devrait paramétrer FLAVORS sur la liste de toutes les options qui ont un sens pour ce port (p. ex., FLAVORS=foo bar zoinx), puis utilisez FLAVOR pour tester quelles options ont réellement été sélectionnées (p. ex., FLAVOR=zoinx foo). bsd.port.mk fournit un peu de support :

  • Le PKGNAME est ajusté pour inclure les options séparées par tiret (p. ex., package-foo-zoinx).
  • Le WRKDIR est ajusté afin que des saveurs distinctes puissent être construites en parallèle sans collision.
  • Les constructions de la forme flavor déclencheront l'inclusion de PFRAG.flavor.
  • bsd.port.subdir.mk comprend l'extension SUBDIR=directory,opt1,opt2 pour dire “build port in directory with FLAVOR=opt1 opt2”.

Vérifier le choix d'une saveur donnée est aussi simple que :

  .if ${FLAVOR:L:Mzoinx}

Il existe une extension supplémentaire, connue comme MULTI_PACKAGES. Généralement, MULTI_PACKAGES et FLAVORS sont des mécanismes orthogonaux. Ensemble, ils tiennent compte du fait que l'arborescence des ports d'OpenBSD est un peu plus petite que celles des autres BSD, ainsi ils permettent à un seul répertoire unique de construire beaucoup de packages distincts. bsd.port.mk(5) contient une section complète consacrée à FLAVORS ET MULTI_PACKAGES.


Cette page est la traduction officieuse de la page «Ports - Differences from Other BSD Projects» 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.