[OpenBSD]

[Index de la FAQ] [Section 14 - Configuration des disques]

15 - Système de Ports et de Paquetages OpenBSD


Table des matières


15.1 - Introduction

Il y a quantité d'applications tierces disponibles dont une que l'on souhaiterait utiliser sur un système OpenBSD. Pour faire en sorte que ce logiciel soit plus simple à installer et à administrer, et aussi pour l'aider à suivre la politique et les objectifs d'OpenBSD, ce logiciel tiers est porté sur OpenBSD. Cet effort de portage peut impliquer plusieurs choses différentes. Par exemples : faire en sorte que le logiciel utilise les répertoires standards d'OpenBSD (exemple : les fichiers de configuration vont dans /etc), se conformer aux spécifications des librairies partagées d'OpenBSD, faire en sorte que le logiciel soit plus sécurisé autant que possible, etc...

Le résultat final de l'effort de portage sont des paquetages binaires prêts à être installés. Le but du système de paquetages est de garder une trace des logiciels installés, de sorte qu'à n'importe quel moment on puisse le mettre à jour ou le supprimer très simplement. De cette façon, il ne reste aucune trace de fichiers inutiles et les utilisateurs peuvent garder leur système propre. Le système de paquetage s'assure également qu'aucun fichier pouvant empêcher un logiciel de fonctionner correctement ne soit supprimé. Un autre avantage est que les utilisateurs ont rarement le besoin de compiler un logiciel à partir des sources, alors que les paquetages sont déjà compilés, disponibles et prêts à être utilisés sur un système OpenBSD. En quelques minutes, un grand nombre de paquetages peuvent être récupérés et installés avec tout à la bonne place.

Les paquetages et la collection des ports NE passent PAS par le même audit complet de sécurité qui est réalisé sur le système de base d'OpenBSD. Bien que nous tâchions de maintenir la qualité de la collection des paquetages élevée, nous n'avons juste pas assez de ressources humaines pour assurer le même niveau de robustesse et de sécurité. Bien évidemment les mises à jour de sécurité pour différentes applications sont intégrées dans l'arbre des ports aussi rapidement que possible, et les mises à jour de sécurité des paquetages correspondants sont mises à disposition des snapshots de -current.

15.2 - Gestion des paquetages

15.2.1 - Comment cela fonctionne-t-il ?

Les paquetages sont les binaires pré-compilés d'une partie des logiciels tiers les plus utilisés. Les paquetages peuvent être gérés facilement avec l'aide de plusieurs utilitaires, également désignés comme les outils pkg* :

Afin de fonctionner correctement, une application X peut exiger que d'autres applications Y et Z soient installées. L'application X serait dépendante de ces autres applications, c'est pourquoi Y et Z s'appellent les dépendances de X. Alternativement, Y peut exiger d'autres applications P et Q, et Z peut exiger l'application R pour fonctionner correctement. De cette façon, un arbre entier de dépendance est formé.

Les paquetages ressemblent à de simples archives .tgz. En soit, ils ne sont que de simples archives .tgz. Mais il y a cependant une différence cruciale : ils contiennent des informations supplémentaires sur le paquetage. Ces informations sont utilisées par pkg_add(1) dans plusieurs buts :

15.2.2 - Faire les choses simplement: PKG_PATH

Vous pouvez faire les choses vraiment très simplement en utilisant la variable d'environnement PKG_PATH. Faites-la juste pointer à votre endroit favoris, et pkg_add(1) ira automatiquement regarder les paquetages que vous spécifierez, et aussi récupérera et installera automatiquement les dépendances nécessaires à ce paquetage.

Une liste des endroits possibles pour récupérer des paquetages est donnée dans la section suivante.

Exemple 1: récupérer de votre CDROM, en vous assurant qu'il est bien monté sur /mnt/cdrom

$ export PKG_PATH=/mnt/cdrom/5.4/packages/`machine -a`/

Exemple 2: récupérer d'un miroir FTP proche

$ export PKG_PATH=ftp://your.ftp.mirror/pub/OpenBSD/5.4/packages/`machine -a`/

C'est habituellement une bonne idée d'ajouter une ligne similaire aux exemples ci-dessus dans votre ~/.profile. Comme avec la variable classique PATH, vous pouvez spécifier plusieurs endroits séparés par deux points. Avant OpenBSD 4.4, tous les chemins de la variable PKG_PATH DOIVENT se terminer par un slash (/). De cette façon, pkg_add(1) peut découper le chemin correctement même s'il possède des URL contenant des deux points. Si la première entrée dans PKG_PATH échoue, la suivante est essayée, ainsi de suite, jusqu'à ce que le paquetage soit trouvé. Si toutes les entrées échouent, une erreur est générée.

Il est à noter l'utilisation de machine(1) dans les lignes de commandes précédentes. Cela va automatiquement substituer votre "architecture d'application" OpenBSD installée, qui est normalement, mais pas toujours, le nom de votre plate-forme. Bien sûr, si vous utilisez les snapshots, vous devrez remplacer "5.4" par "snapshots".

15.2.3 - Trouver des paquetages

Une large collection de paquetages pré-compilés est disponible pour les architectures les plus courantes. Regardez juste pour vos paquetages à l'un de ces endroits :

Si vous avez l'arbre des ports sur votre système, vous pouvez rapidement trouver le paquetage que vous recherchez comme expliqué dans Rechercher dans l'arbre des ports.

Si vous recherchez un fichier ayant un nom spécifique, installez le paquetage pkglocatedb et utilisez la commande pkg_locate pour trouver quel paquetage(s) contient ce fichier.

Vous pouvez remarquer que certains paquetages sont disponibles dans différentes variétés, formellement appelées saveurs ("flavors"). D'autres sont des morceaux de la même application qui peuvent être installés séparément. Ils sont appelés sous-paquetages ("subpackages"). Cela sera détaillé plus loin dans Utiliser les saveurs ("flavors") et les sous-paquetages ("subpackages") mais cela signifie simplement qu'une saveur est un paquetage installé avec un groupe d'options différentes. Actuellement, plusieurs paquetages possèdent des saveurs, par exemple : le support de base de données, le support de système sans X ou l'ajout de réseaux comme SSL et IPv6. Chaque saveur d'un paquetage aura un suffixe différent dans le nom de son paquetage. Pour des informations plus détaillées sur le nom des paquetages, veuillez vous reporter à packages-specs(7).

Note : Tous les paquetages possibles ne sont pas nécessairement disponibles sur les serveurs FTP ! Certaines applications ne fonctionnent simplement pas sur toutes les architectures. Certaines applications ne peuvent pas être distribuées par FTP (ou CDROM) pour des raisons de licences. Il y a aussi de multiples combinaisons de saveurs d'un port, et le projet OpenBSD ne possède pas les ressources pour les construire toutes. Si vous avez besoin d'une combinaison qui n'est pas disponible, vous devrez fabriquer le port à partir des sources. Pour plus d'informations pour savoir comment faire cela, lire Utiliser les saveurs ("flavors") et les sous-paquetages ("subpackages") dans la section Ports de ce document.

15.2.4 - Installer de nouveaux paquetages

Pour installer de nouveaux paquetages, l'utilitaire pkg_add(1) est utilisé. Si vous avez fait les choses simplement pour vous-même en configurant la variable d'environnement PKG_PATH, vous pouvez juste appeler pkg_add(1) avec le nom du paquetage, comme dans l'exemple simple suivant.
$ sudo pkg_add -v screen-4.0.3p3
parsing screen-4.0.3p3
installed /etc/screenrc from /usr/local/share/examples/screen/screenrc | 71%
screen-4.0.3p3: complete

Dans cet exemple l'option -v a été utilisée pour obtenir une sortie plus bavarde. Cette option n'est pas nécessaire mais elle est utile pour déboguer et a été utilisée ici pour donner un peu plus de perspicacité dans ce que pkg_add(1) est en train de faire. Notez le message mentionnant /etc/screenrc. Spécifier plusieurs fois l'option -v produira une sortie encore plus bavarde.

Utiliser pkg_add(1) en mode interactif

pkg_add(1) possède un mode interactif qui peut être activé en l'invoquant avec l'option -i, et cela aura pour conséquence de vous poser des questions quand il ne pourra pas prendre des décisions par lui-même. Par exemple, si vous ne connaissez pas le numéro de version d'un paquetage à l'avance, vous pouvez essayer quelque chose comme :
$ sudo pkg_add -i screen
Ambiguous: screen could be screen-4.0.3p3 screen-4.0.3p3-shm
Choose one package
         0: <None>
         1: screen-4.0.3p3
         2: screen-4.0.3p3-shm
Your choice: 1
screen-4.0.3p3: complete

Pour certains paquetages, des informations additionnelles importantes vous seront données par rapport à la configuration ou l'utilisation de l'application sur un système OpenBSD. Comme c'est important, elles seront affichées que vous utilisiez ou non l'option -v. Considérez l'exemple suivant:

$ sudo pkg_add ghostscript-fonts-8.11
ghostscript-fonts-8.11: complete
You may wish to update your font path for /usr/local/share/ghostscript/fonts
--- ghostscript-fonts-8.11 -------------------
To install these fonts for X11, just make sure that the fontpath
lists the 75dpi or 100dpi bitmap fonts before the ghostscript fonts,
and make sure you have the string ":unscaled" appended to the bitmap
font's fontpath. This way, the bitmap fonts will be used if they
match, and the Type 1 versions will be used if the font needs to be
scaled. Below is the relevant section from a typical xorg.conf file.

   FontPath   "/usr/X11R6/lib/X11/fonts/misc/"
   FontPath   "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
   FontPath   "/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
   FontPath   "/usr/local/lib/X11/fonts/ghostscript/"
   FontPath   "/usr/X11R6/lib/X11/fonts/Type1/"

Continuons maintenant avec l'exemple d'un paquetage qui possède des dépendances :

$ sudo pkg_add -v tin-1.8.2p0
parsing tin-1.8.2p0
Dependencies for tin-1.6.2 resolve to: gettext-0.14.6, libutf8-0.8, pcre-6.4p1, libiconv-1.9.2p3 (todo: libiconv-1.9.2p3,gettext-0.14.6,pcre-6.4p1,libutf8-0.8)
tin-1.8.2p0:parsing libiconv-1.9.2p3
tin-1.8.2p0:libiconv-1.9.2p3: complete
tin-1.8.2p0:parsing gettext-0.14.6
Dependencies for gettext-0.14.6 resolve to: expat-2.0.0, libiconv-1.9.2p3 (todo: expat-2.0.0)
tin-1.8.2p0:parsing expat-2.0.0
tin-1.8.2p0:expat-2.0.0: complete
tin-1.8.2p0:gettext-0.14.6: complete
tin-1.8.2p0:parsing pcre-6.4p1
tin-1.8.2p0:pcre-6.4p1: complete
tin-1.8.2p0:parsing libutf8-0.8
tin-1.8.2p0:libutf8-0.8: complete
tin-1.8.2p0: complete
Encore une fois nous avons ajouté l'option -v pour en voir plus de ce qui se passe. Après des investigations dans les informations du paquetage, des dépendances ont été trouvées et celles-ci ont été installées en premier. Quelque part au milieu vous pouvez voir le paquetage gettext qui a été installé, qui dépendait de libiconv. Avant d'installer gettext, les informations sur le paquetage ont été examinées et il a été vérifié que libiconv a bien été installé.

Il est possible de spécifier plusieurs noms de paquetages sur une ligne, ils seront tous installés en une fois avec les dépendances possibles.

Si pour une raison vous décidez de ne pas utiliser PKG_PATH, il est aussi possible de spécifier la position absolue d'un paquetage via la ligne de commande. Cette position absolue doit être un chemin local ou une URL se référant à une position FTP, HTTP ou SCP. Considérons l'installation via FTP dans l'exemple suivant:

$ sudo pkg_add ftp://ftp.openbsd.org/pub/OpenBSD/5.4/packages/`machine -a`/screen-4.0.3p3.tgz
screen-4.0.3p3: complete

Dans cet exemple l'option -v n'a pas été utilisée donc seulement les messages nécessaires ont été affichés. Vous pouvez noter que le nom de fichier complet a été tapé en ajoutant le suffixe .tgz. Vous pouvez aussi ne pas mettre le suffixe comme dans les exemples précédents car il est auto-complété par pkg_add(1).

Note : Toutes les architectures n'ont pas les mêmes paquetages disponibles. Certains ports ne fonctionnent pas sur certaines architectures, et les performances limitent le nombre de paquetages qui peuvent être construit.

Par sécurité, si vous installez un paquetage que vous avez déjà installé et supprimé précédemment (ou une ancienne version de celui-ci), pkg_add(1) ne réécrira pas les fichiers de configuration qui ont été modifiés. À la place, il vous en informera comme dans l'exemple suivant (seulement en utilisant l'option -v, cependant !) :

$ sudo pkg_add -v screen-4.0.3p3
parsing screen-4.0.3p3
The existing file /etc/screenrc has NOT been changed**                 | 71%
It does NOT match the sample file /usr/local/share/examples/screen/screenrc
You may wish to update it manually
screen-4.0.3p3: complete
Quelquefois vous pouvez rencontrer une erreur comme dans l'exemple suivant :
$ sudo pkg_add xv-3.10ap4
xv-3.10ap4:jpeg-6bp3: complete
xv-3.10ap4:png-1.2.14p0: complete
xv-3.10ap4:tiff-3.8.2p0: complete
Can't install xv-3.10ap4: lib not found X11.9.0
Even by looking in the dependency tree:
        tiff-3.8.2p0, jpeg-6bp3, png-1.2.14p0
Maybe it's in a dependent package, but not tagged with @lib ?
(check with pkg_info -K -L)
If you are still running 3.6 packages, update them.
Il y a pkg_add(1) installant bien des dépendances, quand soudain l'installation de xv est avortée. C'est une autre mesure de sécurité qui est disponible depuis OpenBSD 3.7. Les informations sur le paquetage embarquées dans le paquetage lui-même incluent des informations sur les librairies partagées que le paquetage espère être déjà installées, les librairies systèmes comme les librairies tierces. Si une des librairies nécessaires ne peut pas être trouvée, le paquetage ne sera pas installé car il ne fonctionnerait pas de toute façon.

Pour résoudre ce type de conflit, vous devez découvrir quoi installer dans l'ordre afin d'obtenir les bibliothèques nécessaires sur votre système. Il y a plusieurs choses à vérifier :

15.2.5 - Lister les paquetages installés

Vous pouvez voir une liste des paquetages installés en utilisant l'utilitaire pkg_info(1).
$ pkg_info
aterm-0.4.2p1       color vt102 terminal emulator with transparency support
bzip2-1.0.4         block-sorting file compressor, unencumbered
expat-2.0.0         XML 1.0 parser written in C
fluxbox-0.9.15.1p0  window manager based on the original Blackbox code
gettext-0.14.6      GNU gettext
imlib2-1.3.0        image manipulation library
jpeg-6bp3           IJG's JPEG compression utilities
libiconv-1.9.2p3    character set conversion library
libltdl-1.5.22p1    GNU libtool system independent dlopen wrapper
libungif-4.1.4p0    tools and library routines for working with GIF images
libutf8-0.8         provides UTF-8 locale support
mutt-1.4.2.2i       tty-based e-mail client
pcre-6.4p1          perl-compatible regular expression library
png-1.2.14p0        library for manipulating PNG images
screen-4.0.3p3      multi-screen window manager
tcsh-6.14.00p1      extended C-shell with many useful features
tiff-3.8.2p0        tools and library routines for working with TIFF images
tin-1.8.2p0         threaded NNTP and spool based UseNet newsreader

En donnant le nom d'un paquetage installé (ou l'endroit où se trouve un paquetage qui doit être installé), pkg_info(1) donnera plus d'informations détaillées sur ce paquetage spécifique.

15.2.6 - Mettre à jour les paquetages installés

Disons que vous avez une vieille version de unzip installée avant de mettre à jour cette machine d'OpenBSD 5.3 à 5.4. Maintenant vous pouvez simplement mettre à jour vers le nouveau paquetage 5.4 comme suit :
$ sudo pkg_add -u unzip
unzip-5.52p0 (extracting): complete
unzip-5.52 (deleting): complete
unzip-5.52p0 (installing): complete
Clean shared items: complete

Invoquer pkg_add(1) avec l'option -u et sans nom de paquetage va tenter de mettre à jour tous les paquetages installés. Examiner tous les paquetages installés pour des versions mises à jour. Quand un paquetage possède des dépendances, elles seront aussi examinées pour mises à jour.

Note : Le mécanisme -u est relié à la variable d'environnement PKG_PATH. Si elle n'est pas définie, pkg_add(1) ne sera pas capable de trouver les mises à jour.

Le fait d'avoir plusieurs entrées dans PKG_PATH ne veut pas dire que toutes les entrées seront vérifiées à la recherche de mises à jour. Au lieu de cela, pkg_add(1) s'arrêtera à la première entrée qui contient des candidats convenables.

Si vous aviez un fichier de configuration appartenant à la vieille version que vous avez modifié, il sera laissé intact par défaut. Vous pouvez, cependant, le remplacer par le fichier de configuration de la nouvelle version en appelant pkg_add(1) avec l'option -c.

15.2.7 - Supprimer les paquetages installés

Pour supprimer un paquetage, il suffit de prendre simplement le nom propre du paquetage comme vu avec pkg_info(1) (regardez Lister les paquetages installés ci-dessus) et utilisez pkg_delete(1) pour supprimer le paquetage. Dans l'exemple suivant le paquetage screen sera supprimé. Notez que dans certaines occasions il y a des instructions sur des éléments supplémentaires qui ont besoin d'être supprimés que pkg_delete(1) ne supprimera pas pour vous. Comme avec l'utilitaire pkg_add(1), vous pouvez utiliser l'option -v pour obtenir une sortie plus bavarde.

$ sudo pkg_delete screen
screen-4.0.3p3: complete
Clean shared items: complete

Note : Souvent, il n'est pas nécessaire de spécifier le numéro de version et les saveurs avec le nom du paquetage, puisque pkg_delete(1) sera capable de trouver le nom du paquetage complet de lui-même. Vous devez spécifier le nom complet du paquetage (dans l'exemple c'est screen-4.0.3p3) seulement si une ambiguïté est possible due à l'installation multiple de paquetages avec le nom spécifié. Dans ce cas pkg_delete(1) ne peut pas savoir quel paquetage supprimer.

Par précaution, pkg_delete(1) ne supprimera pas des fichiers de configuration s'ils ont été modifiés. Au lieu de cela il vous en informera comme suit :

$ sudo pkg_delete screen
screen-4.0.3p3: complete
Clean shared items: complete
--- screen-4.0.3p3 -------------------
You should also remove /etc/screenrc (which was modified)

Si vous préférez avoir ces fichiers de configuration supprimés automatiquement, vous pouvez le faire en utilisant l'option -c.

15.2.8 - Suppression ou installation incomplète de paquetage

Dans quelques rares cas, vous pouvez avoir un paquetage qui n'a pas été installé ou supprimé complètement à cause de conflits avec d'autres fichiers. L'installation incomplète est normalement marquée avec un préfixe "partial-" au nom du paquetage. Cela peut, dans certains cas, intervenir quand vous pressez accidentellement CTRL+C durant l'installation :
$ sudo pkg_add screen-4.0.3p3
screen-4.0.3p3: complete                                                      7%
Adjusting md5 for /usr/local/info/screen.info-3 from 49fb3fe1cc3a3b0057518459811b6dac to 3b9c7811244fb9f8d83bb27d3a0f60d8
/usr/sbin/pkg_add: Installation of screen-4.0.3p3 failed , partial installation recorded as partial-screen-4.0.3p3

C'est toujours une bonne idée de supprimer un paquetage partiel de son système et de corriger les problèmes potentiels qui ont conduit à cette erreur. C'est souvent l'indication que vous n'avez pas un système propre avec tout d'installé à partir des paquetages, mais sûrement des paquetages mélangés avec d'autres logiciels installés à partir des sources.

15.3 - Utilisation des ports

Comme mentionné dans l'introduction, les paquetages sont compilés à partir de l'arbre des ports. Dans cette section nous allons vous expliquer comment l'arbre des ports fonctionne, quand vous devez l'utiliser et comment vous pouvez l'utiliser.

NOTE IMPORTANTE : L'arbre de ports est destiné aux utilisateurs avancés. Tout le monde est encouragé à utiliser les paquetages binaires pré-compilés. NE posez pas de questions de débutant sur les listes de diffusion comme "Comment est-ce que je peux faire fonctionner l'arbre des ports ?". Si vous avez des questions sur l'arbre des ports, il est considéré que vous avez lu les pages du manuel, cette FAQ et que vous êtes capable de travailler avec.

15.3.1 - Comment cela fonctionne-t-il ?

L'arbre des ports, un concept à l'origine emprunté à FreeBSD, est un ensemble de Makefiles, un pour chaque application tierce, pour contrôler

En dehors du Makefile, chaque port contient aussi au moins ce qui suit :

Toutes ces informations sont contenues dans une hiérarchie de répertoires sous /usr/ports. Cette hiérarchie contient trois sous-répertoires spéciaux :

Tous les autres sous-répertoires forment les différentes catégories d'applications, qui contiennent les sous-répertoires des ports réels. Les ports complexes doivent être organisés à un niveau encore plus profond, par exemple s'ils ont un noyau principal et un ensemble d'extensions, ou une version stable et une snapshot de l'application. Tous les répertoires de port doivent contenir un sous-répertoire pkg/ qui contient une liste(s) de paquetage et un fichier de description(s). Ils peuvent aussi contenir un sous-répertoire patches/ et files/, pour les patchs source et les fichiers additionnels, respectivement.

Quand un utilisateur exécute make(1) dans un sous-répertoire d'un port spécifique, le système va récursivement traverser toutes les dépendances de l'arbre, vérifier si les dépendances exigées sont installées, compiler et installer toute dépendance manquante, et enfin continuer la construction du port désiré. Toute la construction se fait dans le répertoire de travail que le port crée. Normalement c'est sous ${WRKOBJDIR}, qui est par défaut /usr/ports/pobj, mais vous pouvez le surcharger (voir Configuration du système des ports). Si WRKOBJDIR a été explicitement désactivé, un sous-répertoire dans le répertoire principal du port (nom du paquetage préfixé par "w-") sera utilisé à la place.

Note : Les ports ne sont jamais directement installés sur votre système ! Ils utilisent un faux répertoire d'installation. Tous ce qui est installé ici est empaqueté ensemble dans un paquetage (qui est stocké dans le sous-répertoire packages/ de l'arbre des ports comme mentionné précédemment). Installer un port signifie réellement : création d'un paquetage, et enfin installation de ce paquetage !

Plus d'informations sur le système des ports peut-être trouvé dans les pages de manuel suivantes :

15.3.2 - Récupérer l'arbre des ports

Avant de continuer, vous devez lire la section sur comment NE PAS mélanger votre système OpenBSD et l'arbre des ports. Dès que vous avez décidé quelle saveur de l'arbre des ports vous désirez, vous pouvez récupérer l'arbre des ports de différentes sources. La table ci-dessous donne une vue d'ensemble d'où vous pouvez trouver les différentes saveurs, et sous quelle forme. Un 'x 'marque la disponibilité et un '-' qu'il n'est pas disponible en utilisant les sources spécifiées.

Source Form Flavor
-release -stable snapshots -current
CD-ROM .tar.gz x - - -
FTP mirrors .tar.gz x - x -
AnonCVS cvs checkout x x - x

Sur le CD-ROM et les miroirs FTP, recherchez un fichier dénommé ports.tar.gz. Vous pouvez désarchiver ("untar") ce fichier dans le répertoire /usr, ce qui va créer /usr/ports, et tous les répertoire en dessous. Par exemple:

$ cd /tmp
$ ftp ftp://ftp.openbsd.org/pub/OpenBSD/5.4/ports.tar.gz
$ cd /usr
$ sudo tar xzf /tmp/ports.tar.gz

Les snapshots disponibles sur les FTP miroirs sont générés quotidiennement de l'arbre des ports -current. Vous pouvez trouver les snapshots dans le répertoire pub/OpenBSD/snapshots/ Si vous utilisez un snapshot de l'arbre des ports, vous devez avoir installé un snapshot correspondant d'OpenBSD. Soyez sûr d'avoir votre arbre des ports et votre système OpenBSD synchrone !

Pour plus d'informations sur la façon d'obtenir l'arbre des ports via AnonCVS, veuillez lire la page AnonCVS qui contient une liste des serveurs disponibles et plusieurs exemples.

15.3.3 - Configuration du système des ports

NOTE : Cette section introduit des paramètres de configuration globale additionnels pour construire des applications des ports. Vous pouvez sauter cette section, mais alors vous devrez exécuter plusieurs fois make(1) dans les exemples comme root.

Parce que le projet OpenBSD ne possède pas les ressources pour auditer tout le code source de toutes les applications dans l'arbre des ports, vous pouvez configurer le système de port pour prendre quelques mesures de sécurité. L'infrastructure des ports est capable d'exécuter toute la construction comme un utilisateur normal, et d'exécuter seulement les étapes qui exigent des privilèges de super-utilisateur comme root. Les exemples sont les fausses créations et installations de cibles. Cependant, parce que les privilèges root sont toujours requis à un certain point, le système de port ne vous sauvera pas quand vous déciderez de construire une application malveillante.

Il est possible d'utiliser un arbre des ports en lecture seulement en séparant les répertoires qui sont écrits durant la construction du port :

Par exemple, vous pouvez ajouter les lignes suivantes dans /etc/mk.conf
WRKOBJDIR=/usr/obj/ports
DISTDIR=/usr/distfiles
PACKAGE_REPOSITORY=/usr/packages
Si désiré, vous pouvez aussi changer les droits de propriété de ces répertoires par votre nom d'utilisateur et de groupe local, de sorte que le système des ports puisse créer les répertoires de travail correspondants comme un utilisateur normal.

15.3.4 - Rechercher dans l'arbre des ports

Dès que vous avez l'arbre des ports en place sur votre système, il devient très simple de rechercher un logiciel. Il faut juste utiliser make search key="searchkey", comme montré dans l'exemple suivant.
$ cd /usr/ports
$ make search key=rsnapshot
Port:   rsnapshot-1.3.1p0
Path:   net/rsnapshot
Info:   remote filesystem snapshot utility
Maint:  Antoine Jacoutot <ajacoutot@openbsd.org>
Index:  net sysutils
L-deps:
B-deps: :net/rsync
R-deps: :devel/p5-Lchown :net/rsync
Archs:  any
Le résultat de la recherche donne une sympathique vue d'ensemble de chaque application qui a été trouvée : le nom du port, le chemin vers le port, une ligne de description, le mainteneur du port, les mots clés relatifs au port, les dépendances de librairies/compilation/exécutables, et l'architecture sur laquelle le port est connu pour fonctionner.

Ce mécanisme, cependant, est très basique, il exécute juste awk(1) sur le fichier d'index des ports. Depuis OpenBSD 4.0, un nouveau port appelé "sqlports" a été créé, permettant de faire des recherches en utilisant SQL de manière très précise. C'est une base de donnée SQLite, mais fondamentalement n'importe quel format de base de données peut être créé pour être utilisé dans l'infrastructure des ports. Le port de sqlports inclut le script utilisé pour générer la base de données, qui pourrait être utilisé comme base pour générer des bases de données dans des formats différents.

Il faut juste pkg_add(1)'er le paquetage sqlports. Un simple session devrait ressembler à :

$ sqlite3 /usr/local/share/sqlports
SQLite version 3.3.12
Enter ".help" for instructions
sqlite> SELECT FULLPKGNAME,COMMENT FROM Ports WHERE COMMENT LIKE '%statistics%'; 
Guppi-0.40.3p1|GNOME-based plot program with statistics capabilities
mailgraph-1.12|a RRDtool frontend for Postfix statistics
R-2.4.1|clone of S, a powerful math/statistics/graphics language
py-probstat-0.912p0|probability and statistics utilities for Python
darkstat-3.0.540p1|network statistics gatherer with graphs
pfstat-2.2p0|packet filter statistics visualization
tcpstat-1.4|report network interface statistics
wmwave-0.4p2|Window Maker dockapp to display wavelan statistics
diffstat-1.43p0|accumulates and displays statistics from a diff file
sqlite>
L'exemple ci-dessus reste un recherche très simple. Avec SQL, à peu près tout peut être recherché, incluant les dépendances, les options de configuration, librairies partagées, etc...

15.3.5 - Installation normale : un exemple simple

Pour clarifier les choses, considérons un exemple simple : rsnapshot. Cette application possède une dépendance : rsync.
$ cd /usr/ports/net/rsnapshot
$ make install
===>  Checking files for rsnapshot-1.2.9
>> rsnapshot-1.2.9.tar.gz doesn't seem to exist on this system.
>> Fetch http://www.rsnapshot.org/downloads/rsnapshot-1.2.9.tar.gz.
100% |**************************************************|   173 KB    00:02
>> Size matches for /usr/ports/distfiles/rsnapshot-1.2.9.tar.gz
>> Checksum OK for rsnapshot-1.2.9.tar.gz. (sha1)
===>  rsnapshot-1.2.9 depends on: rsync-2.6.9 - not found
===>  Verifying install for rsync-2.6.9 in net/rsync
===>  Checking files for rsync-2.6.9
>> rsync-2.6.9.tar.gz doesn't seem to exist on this system.
>> Fetch ftp://ftp.samba.org/pub/rsync/old-versions/rsync-2.6.9.tar.gz.
100% |**************************************************|   792 KB 00:31
>> Size matches for /usr/ports/distfiles/rsync-2.6.9.tar.gz
>> Checksum OK for rsync-2.6.9.tar.gz. (sha1)
===>  Verifying specs:  c
===>  found c.40.3
===>  Extracting for rsync-2.6.9
===>  Patching for rsync-2.6.9
===>  Configuring for rsync-2.6.9
  [...snip...]
===>  Building for rsync-2.6.9
  [...snip...]
===>  Faking installation for rsync-2.6.9
  [...snip...]
===>  Building package for rsync-2.6.9
Link to /usr/ports/packages/i386/ftp/rsync-2.6.9.tgz
Link to /usr/ports/packages/i386/cdrom/rsync-2.6.9.tgz
===>  Installing rsync-2.6.9 from /usr/ports/packages/i386/all/rsync-2.6.9.tgz
rsync-2.6.9: complete
===> Returning to build of rsnapshot-1.2.9
===>  rsnapshot-1.2.9 depends on: rsync-2.6.9 - found
===>  Extracting for rsnapshot-1.2.9
===>  Patching for rsnapshot-1.2.9
===>  Configuring for rsnapshot-1.2.9
  [...snip...]
===>  Building for rsnapshot-1.2.9
  [...snip...]
===>  Faking installation for rsnapshot-1.2.9
  [...snip...]
===>  Building package for rsnapshot-1.2.9
Link to /usr/ports/packages/i386/ftp/rsnapshot-1.2.9.tgz
Link to /usr/ports/packages/i386/cdrom/rsnapshot-1.2.9.tgz
===>  rsnapshot-1.2.9 depends on: rsync-2.6.9 - found
===>  Installing rsnapshot-1.2.9 from /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz
rsnapshot-1.2.9: complete

Comme vous pouvez le voir, le système des ports fait beaucoup de choses automatiquement. Il récupère, extrait, modifie le code source, configure et construit (compile) le code source, installe les fichiers dans un faux répertoire, crée un paquetage (correspondant à la liste de paquetage) et installe ce paquetage sur votre système (usuellement sous /usr/local/). Et il fait cela récursivement pour toutes les dépendances du port. Il faut juste voir les lignes "===> Verifying install for ..." et "===> Returning to build of ..." dans la sortie ci-dessus, indiquant le chemin à travers l'arbre des dépendances.

Si une version précédente de l'application que vous voulez installer a déjà été installée sur votre système, vous pouvez utiliser make update à la place de make install. Cela appellera pkg_add(1) avec l'option -r.

Note : Les grosses applications nécessitent une quantité importante de ressources système pour être construites. De bons exemples sont les compilateurs comme GCC 4.0 ou le Java 2 Software Development Kit. Si vous obtenez des erreurs du type "out of memory" quand vous construisez ce type de port, ceci a habituellement une de ces deux causes :

15.3.6 - Nettoyer après une compilation

Vous voulez probablement nettoyer le répertoire de travail par défaut du port après avoir construit et installé le paquetage.
$ make clean
===>  Cleaning for rsnapshot-1.2.9
En outre, vous pouvez aussi nettoyer les répertoires de travail de toutes les dépendances du port avec cette cible de make :
$ make clean=depends
===>  Cleaning for rsync-2.6.9
===>  Cleaning for rsnapshot-1.2.9
Si vous désirez supprimer l'ensemble des sources de la distribution du port, vous pouvez utiliser
$ make clean=dist
===>  Cleaning for rsnapshot-1.2.9
===>  Dist cleaning for rsnapshot-1.2.9
Dans le cas où vous avez compilé de multiples saveurs du même port, vous pouvez nettoyer les répertoires de travail de toutes ces saveurs en une fois en utilisant
$ make clean=flavors
Vous pouvez aussi effectuer un nettoyage au fur et à mesure que la compilation a lieu en positionnant une variable spéciale. Les répertoires de compilation seront automatiquement nettoyés une fois les paquetages créés :
$ make package BULK=Yes

15.3.7 - Désinstaller un paquetage de port

Il est très simple de désinstaller un port :
$ make uninstall
===> Deinstalling for rsnapshot-1.2.9
rsnapshot-1.2.9: complete
Clean shared items: complete
Cela appellera pkg_delete(1) pour avoir le paquetage correspondant supprimé de votre système. Si vous le désirez, vous pouvez aussi désinstaller et réinstaller un paquetage de port en utilisant
$ make reinstall
===>  Cleaning for rsnapshot-1.2.9
/usr/sbin/pkg_delete rsnapshot-1.2.9
rsnapshot-1.2.9: complete
Clean shared items: complete
===>  Installing rsnapshot-1.2.9 from /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz
rsnapshot-1.2.9: complete
Si vous voudriez vous débarrasser des paquetages que vous avez juste construit, vous pouvez faire comme suit :
$ make clean=packages
===>  Cleaning for rsnapshot-1.2.9
rm -f /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz

15.3.8 - Utiliser les saveurs ("flavors") et les sous-paquetages ("subpackages")

Veuillez lire la page du manuel ports(7) qui donne une bonne vue d'ensemble du sujet. Il y a deux mécanismes pour contrôler le paquetage d'un logiciel en fonction des différents besoins.

Le premier mécanisme est appelé saveurs ("flavors"). Une saveur indique habituellement un certain ensemble d'options de compilation. Par exemple, quelques applications ont une saveur "no_x11" qui peut être employée sur des systèmes sans X. Certains shells possèdent une saveur "static", qui construira une version avec les librairies liées statiquement. Il y a des ports qui ont différentes saveurs pour les construire avec différents toolkits graphiques. D'autres exemples incluent : le support pour différents formats de bases de données, différentes options réseaux (SSL, IPv6, ...), différentes taille de papiers, etc...

Résumé : Très probablement vous emploierez des saveurs quand un paquet n'a pas été rendu disponible pour la saveur que vous recherchez. Dans ce cas-ci vous indiquerez la saveur désirée et construirez le port vous-même.

La plupart des saveurs de ports auront leur propre répertoire de travail durant leur construction et chaque saveur sera packagée avec un nom de paquetage correspondant pour éviter toute confusion. Pour voir les différentes saveurs d'un port, vous devrez aller dans son sous-répertoire et taper

$ make show=FLAVORS
Vous devriez aussi regarder les fichiers DESCR d'un port étant donné qu'ils sont supposés décrire les saveurs disponibles.

Le second mécanisme est appelé sous-paquetages ("subpackages"). Un porteur de paquetage peut décider de créer des sous-paquetages pour différentes parties de la même application, si elles peuvent être logiquement séparées. Vous verrez souvent des sous-paquetages pour la partie cliente et pour la partie serveur d'un programme. Quelquefois une documentation importante est livrée dans un sous-paquetage séparé parce qu'elle prend trop d'espace disque. Toute fonctionnalité additionnelle qui a beaucoup de dépendances sera souvent packagée séparément. La personne effectuant le portage devra aussi décider quel sous-paquetage est considéré comme principal, à installer par défaut. D'autres exemples incluent : des suites de tests importants qui sont fournis avec le logiciel, des modules séparés pour supporter différentes choses, etc...

Résumé : Certains ports sont répartis en plusieurs paquetages. make install va uniquement installer le sous-paquetage principal.

Pour afficher les différents paquetages émanant d'un port donné, utilisez :

$ make show=PKGNAMES

make install installera uniquement le premier sous-paquetage. Pour les installer tous, utilisez :

$ make install-all

Pour afficher les différents sous-paquetages disponibles pour un port, utilisez

$ make show=MULTI_PACKAGES
Il est possible de sélectionner quel(s) sous-paquetage(s) à installer à partir de l'arbre des ports. Après quelques tests, cette procédure appellera juste pkg_add(1) pour installer le(s) sous-paquetage(s) désiré(s).
$ env SUBPACKAGE="-server" make install

Note : Le mécanisme de sous-paquetage manipule seulement des paquetages, il ne modifie aucune option de configuration avant de construire le port. Dans ce but vous devez employer les saveurs.

15.3.9 - Utiliser dpb pour construire plusieurs ports

Lorsque vous devez construire plus d'un ou deux ports à la fois, vous pouvez utiliser l'utilitaire dpb(1) fourni dans /usr/ports/infrastructure/bin. dpb(1) prend une liste de ports à construire et les construit automatiquement dans un ordre optimal, en étant le plus parallèle possible. Il peut également utiliser de multiples machines pour effectuer la construction. Il produit des logs détaillés du processus de construction pour dépannage, par défaut dans /usr/ports/log.
/usr/ports/infrastructure/bin/dpb -P ~/localports
va lire la liste des pkgpaths (pkgpath(7)) dans ~/localports et construire tous les paquetages. Cela peut aussi installer les paquetages après qu'ils aient été construits. ~/localports devrait ressembler à:
net/cvsync
www/mozilla-firefox
net/rsync
net/nfsen
textproc/mupdf
misc/magicpoint
lang/sbcl
editors/emacs
Si vous ne fournissez pas une liste de ports à construire dans la ligne de commande ou via -P ou -I, dpb(1) va construire tous les ports de l'arbre des ports.

15.3.10 - Mises à jour de sécurité (-stable)

Quand un bogue sérieux ou une faille de sécurité sont découverts dans un logiciel tiers, ils sont corrigés dans la branche -stable de l'arbre des ports. Contrairement à l'OS de base, le cycle de vie est de 1 version : seule la version -current et la dernière release sont mises à jour, comme expliqué dans FAQ 5 - Saveurs ("Flavors") OpenBSD.

Cela signifie que tous ce que vous devez faire est de s'assurer d'avoir récupéré la branche correcte de l'arbre de ports, et de construire le logiciel désiré de celui-ci. Vous pouvez avoir un arbre mis à jour avec CVS, et en plus s'abonner à la liste de diffusion ports-changes pour recevoir les annonces de sécurité relatives aux logiciels dans l'arbre des ports.

Bien évidemment, les mises à jour de sécurité sont effectuées sur l'arbre des ports -current avant d'être intégrées dans la branche -stable.

15.3.11 - Signatures des paquetages

Les signatures sont un bon moyen pour être sûr que les paquetages sont légitimes et non corrompus.

Pour démarrer la construction de la signature des paquetages, nous avons besoin en premier de créer un certificat racine CA (autorité de certification) et une clé. Dans cette exemple, nous utiliserons une validité de 10 ans.

# openssl req -x509 -days 3650 -newkey rsa:2048 -keyout /etc/ssl/private/pkgca.key -out /etc/ssl/pkgca.pem
Maintenant nous allons créer une certificat build et une clé que nous utiliserons pour signer nos paquetages. Pour cet exemple, nous utiliserons une validité de 1 an. Nous allons aussi créer la demande correspondante de signature de certificat qui sera utilisée par notre CA pour signer le certificat.
# openssl genrsa -out /etc/ssl/private/pkg.key 2048
# openssl req -new -key /etc/ssl/private/pkg.key -out /etc/ssl/private/pkg.csr
Maintenant nous allons signer le certificat en utilisant la CA que nous avons créée lors de la première étape.
# openssl x509 -req -days 365 -in /etc/ssl/private/pkg.csr -CA /etc/ssl/pkgca.pem -CAkey /etc/ssl/private/pkgca.key -CAcreateserial -out /etc/ssl/pkg.crt
# rm /etc/ssl/private/pkg.csr

Finalement, nous ajoutons la ligne suivante à /etc/mk.conf pour construire des paquetages signés par défaut.

PKG_CREATE=/usr/sbin/pkg_create -s x509 -s /etc/ssl/pkg.crt -s /etc/ssl/private/pkg.key

Quand on installe des paquetages signés, vous verrez une ligne supplémentaire à la fin de la sortie qui vous informe du nombre de paquetages signés que vous avez installé.

$ sudo pkg_add vte-0.24.3.tgz
vte-0.24.3: ok
Packages with signatures: 1

Si vous avez des problèmes avec des paquetages signés (par exemple certificat expiré...), vous pouvez forcer la (re-)installation et/ou suppression en utilisant une des commandes suivantes (en fonction de ce que vous voulez faire) :

$ sudo pkg_add -r -D installed PKGNAME
$ sudo pkg_add -D nosig PKGNAME
$ sudo pkg_delete -q PKGNAME

15.4 - FAQ

15.4.1 - J'obtiens toutes sortes d'erreurs folles. Je n'arrive pas du tout à faire fonctionner ces ports.

Il est très probable que vous employiez un système et un arbre des ports qui n'est pas synchrone.

Pardon ?

Un autre erreur courante est l'installation oubliée de X11. Même si le port que vous essayez de construire n'a pas de dépendance directe avec X11, un sous-paquetage ou ces dépendances peuvent avoir besoin des entêtes X11 ou des librairies. Construire des ports sur un système sans X11 n'est pas supporté, même si vous insistez pour le faire ainsi, vous serez seul pour le gérer. Pour plusieurs ports, il y a cependant, la saveur de paquetage "no_x11" disponible, avec laquelle vous pouvez installer sans avoir besoin de X11 sur votre système.

15.4.2 - Pourquoi la dernière version de mon logiciel favori/préféré n'est pas disponible ?

Si vous utilisez une version révision ou stable d'OpenBSD, vous ne trouverez pas de mise à jour de paquetage avant la prochaine révision, ou alors si un problème de sécurité intervient et justifie une mise à jour du port dans la branche -stable et du paquetage correspondant.

ATTENTION : NE PAS mélanger les versions des Ports et d'OpenBSD :

En faisant ainsi tôt ou tard (probablement très tôt en fait) cela va vous causer des maux de tête en essayant de résoudre toutes sortes d'erreurs !

Mais hé, je suis en -current ici !

La collection des ports est un projet de volontaires. Quelquefois le projet n'a simplement pas les ressources en développeur pour avoir tout de mis à jour en permanence. Les développeurs assez souvent reprennent ce qui les intéresse et ce qu'ils peuvent tester dans leur environnement. Quelques ports isolés peuvent traîner derrière les versions traditionnelles pour cette raison. Important : ne pas mettre à jour à la dernière version est souvent une sage décision. La nouvelle version pourrait avoir des problèmes que le mainteneur tente de résoudre, ou elle peut tout simplement être pire que la précédente. De plus, OpenBSD peut avoir différents buts que les autres principaux développeurs dans d'autres projets, qui quelquefois résultent dans une fonctionnalité et un design ou un choix d'implémentation qui est indésirable du point de vue des développeurs d'OpenBSD. La mise à jour peut également être remise à plus tard parce que la nouvelle version n'est pas considérée comme étant une mise à jour cruciale.

Si vous avez réellement besoin d'une nouvelle version du port, vous pouvez contacter le mainteneur du port pour qu'il le mette à jour (voir ci-dessous comment trouver un mainteneur). Si vous pouvez nous aider avec ceci, tout ira pour le mieux.

15.4.3 - Pourquoi n'y a-t-il pas de paquetage de mon logiciel favori/préféré ?

Il y a plusieurs raisons possibles à cela :

15.4.4 - Pourquoi n'y a-t-il pas de port de mon logiciel favori/préféré ?

La collection des ports est un projet de volontaires. Le développement de port actif est réalisé par un nombre limité de personnes, à leur temps perdu. Ces personnes réalisent souvent de nouveaux ports seulement sur les logiciels qu'ils utilisent directement ou qui les intéressent.

Vous pouvez aider. Voyez pour créer votre propre port. Il y a de la documentation disponible dans : OpenBSD Porter's Handbook. Lisez-la et lisez-la encore. Spécialement la partie sur maintenir votre port. Donc essayez de construire un nouveau port, et testez-le soigneusement point par point. Si finalement il fonctionne parfaitement pour vous, soumettez le à la liste de diffusion des ports à ports@openbsd.org. Vous avez beaucoup de chances de recevoir un retour et des tests d'autres personnes. Si l'essai est réussi, votre port sera considéré comme pris dans l'arbre des ports.

15.4.5 - Pourquoi mon logiciel favori/préféré ne fait pas partie du système de base ?

Puisque OpenBSD est supposé être un petit système d'exploitation Unix-like autonome, nous devons tracer une ligne quant à quoi inclure. Généralement, pour une application qui doit être incluse dans le système de base :

Plus de réponses à cette question peuvent aussi être trouvées dans la FAQ 1.

15.4.6 - Qu'est-ce que je dois utiliser : paquetages ou ports ?

En général, il est fortement conseillé d'utiliser les paquetages au lieu de construire une application des ports. L'équipe des ports d'OpenBSD considère que les paquetages sont le but de leur effort de portage, pas les ports en eux-mêmes.

Construire un application complexe des sources n'est pas trivial. Non seulement l'application doit être compilée, mais les outils utilisés pour la construire doivent être compilés aussi. Malheureusement, OpenBSD, les outils, et les applications sont en évolution, et souvent, obtenir que tous les morceaux fonctionnent ensemble est un défi. Dès que tout fonctionne, une révision d'une des pièces le jour suivant peut tout casser. Tous les six mois, comme une nouvelle révision d'OpenBSD est réalisée, un effort est fait pour tester la construction de chaque port sur toutes les plates-formes, mais durant le cycle de développement il est courant que certains ports soient cassés.

En plus d'avoir toutes les pièces fonctionnant ensemble, il y a juste la matière en temps et ressource requise pour compiler quelques applications des sources. Des applications comme par exemple les produits Mozilla ou KDE prennent des heures et un espace disque énorme en plus de beaucoup de RAM/swap pour les construire. Pourquoi aller vers autant de temps et d'efforts quand les programmes sont déjà compilés et attendent sur votre CD-ROM ou miroir FTP d'être utilisés ?

Bien évidemment, il y a quelques bonnes raisons d'utiliser les ports au lieu des paquetages dans certains cas :

Cependant, pour la plupart des gens et des applications, utiliser les paquetages est plus simple, et définitivement la méthode recommandée pour ajouter des applications à un système OpenBSD.

15.4.7 - Comment puis-je optimiser ces ports pour obtenir le maximum de performance ?

OpenBSD est orienté stabilité et sécurité. Comme le noyau GENERIC qui est par défaut est le seul noyau supporté, l'équipe des ports s'assure que les ports fonctionnent et sont stables. Si vous voulez modifier plusieurs options de compilation, c'est de votre propre chef. Merci de ne pas poser de questions sur les listes de diffusion sur le "pourquoi cela ne fonctionne plus" quand vous essayez quelques options pour que cela s'exécute plus rapidement. En général, toutes ces optimisations ne sont pas nécessaires pour plus de 99% des utilisateurs, et c'est souvent une perte de temps complète pour vous, les utilisateurs, aussi bien que pour les développeurs qui lisent vos "problèmes" alors qu'en réalité il n'y en a aucun.

15.4.8 - J'ai soumis un nouveau port/une mise à jour depuis plusieurs semaines. Pourquoi cela n'a pas été intégré ("commited") ?

L'équipe des ports possède des ressources limitées et aucun "committer" n'est capable de regarder à votre port/mise à jour dans les temps. C'est très frustrant mais ignorez ce fait. Prenez soin de votre port, envoyez des mises à jour et éventuellement quelqu'un s'occupera de lui. Il est déjà arrivé dans le passé que des personnes aient soudain du temps de libre pour intégrer des ports ou que leur intérêt ait changé vers de nouveaux domaines et soudainement votre ancien envoi devient intéressant, si l'on s'en souvient.

15.5 - Comment signaler un problème

Si vous avez des soucis avec un port existant, veuillez envoyer un e-mail au mainteneur du port. Pour voir qui est le mainteneur du port, tapez par exemple :
$ cd /usr/ports/archivers/unzip
$ make show=MAINTAINER

Alternativement, s'il n'y a pas de mainteneur, ou si vous ne pouvez pas le/la contacter, envoyez un e-mail à la liste de diffusion des ports d'OpenBSD ports@openbsd.org. Veuillez NE PAS utiliser la liste de diffusion misc@openbsd.org pour des questions sur les ports.

Dans tous les cas veuillez fournir :

Pour les ports qui ne se construisent pas correctement, un rapport complet de construction est souvent toujours requis. Vous pouvez utiliser le script portslogger, trouvé dans /usr/ports/infrastructure/bin, pour cela. Un exemple d'exécution de portslogger ressemble à :
$ mkdir ~/portslogs
$ cd /usr/ports/archivers/unzip
$ make clean install 2>&1 | /usr/ports/infrastructure/bin/portslogger \
           ~/portslogs
Après cela, vous devez avoir un fichier de log de la construction dans votre répertoire ~/portslogs que vous pouvez envoyer au mainteneur du port. Toutefois, soyez sur que vous n'avez pas utilisé des options spéciales lors de la construction, par exemple dans /etc/mk.conf.

Alternativement, vous pouvez

15.6 - Comment nous aider

Il y a plusieurs façons de nous aider. Elles sont listées ci-dessous, par ordre croissant de difficulté.

Les dons de matériel peuvent aider à tester les ports sur différentes plates-formes supportées par OpenBSD.

Note : Pour toute création de nouveaux ports et des tests conséquents, ou pour tester des mises à jour de port, vous devez avoir un système -current ! En général, ce n'est pas un environnement désirable à cause de ces changements permanents par nature, donc procédez seulement si vous êtes sûr de pouvoir mettre à jour vous-même le système -current.

[FAQ Index] [Section 14 - Configuration des disques]


[back] www@openbsd.org
$OpenBSD: faq15.html,v 1.42 2013/11/16 15:12:55 ajacoutot Exp $