L'arborescence des ports est un ensemble de pièces d'un travail qui permet aux utilisateurs d'OpenBSD d'utiliser des programmes tiers sans perdre du temps à les corriger, configurer, et installer chacun individuellement. Ce travail est fait par un groupe de volontaires qui prennent leur temps à porter et tester des applications sur toute la variété de plates-formes d'OpenBSD.

Beaucoup de personnes pensent qu'ils ne peuvent aider à ce processus parce qu'ils n'ont pas assez de connaissances, mais c'est faux parce qu'ils peuvent aider les porteurs à travailler mieux et plus rapidement. Testez les mises à jour soumises ou les nouveaux ports qui sont postés sur la liste de diffusion ports. En faisant cela, vous réduisez la latence de validation et augmentez le nombre de ports à être validés. Beaucoup de ports ne sont pas validés par manque de tests.

L'arborescence des ports est développée dans -current ; il n'y a aucune garantie que les nouveaux ports ou mises à jour fonctionneront correctement sur les autres branches. Cela signifie que vous devrez mettre à jour votre système et l'arborescence de ports vers -current. Les instructions pour trouver comment faire cela peuvent être trouvées sur la page current suivante. Il vous est aussi recommandé de souscrire aux listes de diffusion ports et ports-changes. De cette manière, vous serez notifié à-propos des nouveaux ports et des mises à jour et des changements dans l'arborescence des ports.

Il y deux types de soumissions sur la liste de mails : les nouveaux ports et les mises à jour. Les nouveaux ports sont généralement postés comme archives attachés ou URL. Une bonne idée est de l'extraire dans le répertoire /usr/ports/mystuff/ et de le tester. Les mises à jour sont généralement un diff de l'arborescence de ports -current, ainsi il est mieux de copier le port vers mystuff/ et d'appliquer le diff pour prévenir une corruption de l'arborescence. Si une version précédente du port est installée, c'est une bonne idée de la supprimer avant de construire la nouvelle version afin de ne pas subir des effets de bords, tels que des liens symboliques manquants d'une ancienne version d'une bibliothèque.

Il est nécessaire de vérifier, étape après étape, que chaque cible soit correctement terminée, lisez ports(7) :

• fetch
  • Besoin de vérifier que le(s) fichier(s) distfile(s) est (sont) correctement téléchargé(s). Essayez de tester tous les MASTER_SITES spécifiés pour vous assurer qu'ils soient tous des sources valides.
• checksum
  • Vérifiez que les fichiers distfiles téléchargés correspondent aux sommes de contrôle enregistrées dans le fichier distinfo. Pour télécharger les fichiers distfiles depuis les sources définies et vérifier leurs sommes de contrôle, vous pouvez utiliser cette ligne de commande à l'intérieur du répertoire du port :

$ for ms in $(make show=MASTER_SITES); do make clean=dist; make fetch checksum MASTER_SITES=$ms; done

• extract
  • La cible prepare est automatiquement invoquée avant extract et devrait installer toutes les {BUILD,LIB}_DEPENDS pour le port (tel que bzip2).
• patch
  • Les correctifs devraient être appliqués proprement sans aucun message d'avertissement.
  • Il ne devrait avoir aucun fichier “.orig” dans le répertoire correctifs/.
  • Une autre erreur commune est d'inclure les étiquettes RCS dans le correctif ; cela cassera quand le port sera vérifié dans le dépôt et que le tag RCS sera publié.
• configure
  • Vérifiez que les scripts configure détectent correctement les fonctionnalités de votre plate-forme.
  • Le script configure ne devrait pas détecter les applications tierces déjà installées sur votre système sans que les dépendances explicites soient paramétrées dans le port.
  • Si le port ne construit pas avec la libtool depuis la base, vous pouvez essayer de configurer USE_LIBTOOL=gnu qui utilise une version corrigée depuis les ports. La libtool GNU est connue notoirement pour avoir des 'fonctionnalités' non désirées sur OpenBSD, ainsi si le port ne construit pas avec la libtool de base, cela devra être corrigé et il devra y avoir les commentaires XXX à-propos des raisons dans le Makefile du port.
  • Si le port utilise CMake et que vous voyez des résultats indésirables durant la phase configure, assurez vous de vérifier ou d'envoyer les fichiers additionnels suivants :
    • ${WRKBUILD}/CMakeCache.txt
    • ${WRKBUILD}/CMakeFiles/CMakeError.log
    • ${WRKBUILD}/CMakeFiles/CMakeOutput.log
• build
  • Vérifiez les erreurs de compilation et les messages d'avertissements suspicieux.
  • Les messages d'avertissements à-propos des problèmes de tmpnam(3) devront être résolus en utilisant mkstemp(3).
  • Essayez de paramétrer la variable SEPARATE_BUILD à 'Yes' et testez si la construction fonctionne toujours.
  • Assurez vous que les dépendances liées à GNU make soient réellement nécessaires.
• test
  • Vérifiez les erreurs (des sorties vides signifient ok).
  • Si les tests ont des dépendances autres que celles spécifiées dans {BUILD,RUN}_DEPENDS, vérifiez que TEST_DEPENDS soit correctement définie.
• fake
  • Cette cible installe l'application dans une simulation de répertoire de travail, pour s'assurer que tous les fichiers peuvent être facilement empaquetés sans affecter le système de base.
  • Le port ne devrait jamais installer de fichier en-dehors du répertoire simulé, tel que dans /usr/local.
  • De temps à autre, GNU libtool a des difficultés pour relier les bibliothèques durant le processus de simulation sur certaines architectures.
  • Vérifier que tous les fichiers soient installés avec les droits corrects et les bonnes permissions.
• port-lib-depends-check
  • Cela vérifiera que toutes les bibliothèques dont dépend chaque port puissent être atteintes via LIB_DEPENDS ou WANTLIB. Le résultat doit être vide. Les variables sus-mentionnées devraient être inspectées quand vous voyez des lignes commençant par “Extra” ou “Missing.”
• package
  • La création des packages peut être cassée si pkg/PLIST* et/ou pkg/PFRAG* sont faux.
• install
  • Les packages doivent installés tous les fichiers depuis leur liste de packages avec succès et avec les permissions correctes. Soyez particulièrement attentif aux fichiers avec le bit setuid paramétré.
  • Assurez-vous que le script INSTALL du package fonctionne correctement et qu'il ne réécrit aucun fichier dans /etc.
• deinstall
  • Ceci doit supprimer tous les fichiers installés par le package, exceptés ceux dans /etc.
  • Les fichiers systèmes créés par le package au moment de l'exécution devraient être marqués avec les annotations @extra et/ou @extraunexec dans pkg/PLIST*.

La grammaire et la typographie des fichiers pkg/ tels que DESCR et MESSAGE devraient être vérifiées. Les paragraphes devraient être formatés par fmt(1) et segmentés tous les 80 caractères.

Une fois les tests finis, une chose réellement importante est à faire : les commentaires. Même si le port fonctionne, les commentaires doivent être faits. Si nous avons dix posts où les personnes disent que le port fonctionne sous différentes architectures, alors la validation est faite rapidement. Si cela ne fonctionne pas, alors quelques informations doivent être données. Il y a des outils pour aider dans cette tâche, tels que portslogger(1) qui est “un outil intelligent” et qui redirige la sortie dans un fichier journal.

Exemple :

  # make install 2>&1 | /usr/ports/infrastructure/bin/portslogger .

Cela redirigera la sortie vers un fichier journal localisé dans le répertoire courant.

Finalement, une fois que le port est reconnu pour être fonctionnel, les autres ports dépendants de celui-ci devront être aussi testés, pour vérifier qu'ils fonctionnent toujours correctement. L'option show-required-by aide à trouver les autres ports qui dépendent du port courant.

Vérifiez les Makefile du port pour corriger les dépendances, la typographie, les liens incorrects, les variables manquantes ou non utilisées, les licences correctes, et les catégories. Ceux qui sont plus qualifiés peuvent examiner les correctifs, aussi bien fournir des fichiers diff pour corriger les bogues, ajouter le support de saveurs, ou d'autres améliorations.

Ces fichiers diff devraient être faits avec les options CVS -uNprx. cvs diff -uNp peut aussi être utilisé pour générer des correctifs dans le dépôt CVS.

Cette page est la traduction officieuse de la page “Ports - Testing 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.