![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[Index de la FAQ] [Section 14 - Configuration des disques]
Il y a quantité d'application tierces disponibles dont une que l'on souhaiterait utiliser sur un système OpenBSD. Pour faire que ce logiciel soit plus simple à installer et à administrer, et aussi pour l'aider à ce qu'il suive 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 que le logiciel utilise les répertoires standards de OpenBSD (exemple : les fichiers de configuration vont dans /etc), se conformer aux spécifications des librairies partagées d'OpenBSD, faire 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'a 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 que rien n'est supprimé par accident, arrétant ainsi le logiciel de fonctionner correctement. 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êt à être utilisé 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 passe 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 élévé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 à la disposition comme expliqué ci-dessous.
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 de 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. Fondamentalement ils sont juste cela, mais il y a une différence cruciale : ils contiennent des informations supplémentaires sur le paquetage. Ces informations sont utilisées par pkg_add(1) pour plusieurs buts :
Vous pouvez faire les choses vraiment trés simplement en utilisant la variable d'environnement PKG_PATH. Faite la juste pointer à votre endroit favoris, et pkg_add(1) ira automatiquement regarder les paquetages que vous spécifierez, et aussi récuperera et installera automatiquement les dépendances nécéssaires à 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 assurant qu'il est bien monter sur /mnt/cdrom
$ export PKG_PATH=/mnt/cdrom/4.1/packages/`machine -a`/
Exemple 2: récupérer d'un miroir FTP proche
$ export PKG_PATH=ftp://your.ftp.mirror/pub/OpenBSD/4.1/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. CEPENDANT, 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 si 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'a ce que le paquetage soit trouvé. Si toutes les entrées échouent, une erreur est générée.
Il est a 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 sur, si vous utilisez les snapshots, vous devrez remplacer "4.1" par "snapshots".
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.
Vous pouvez remarquer que certains paquetages sont disponibles dans différentes variétes, formellement appelées saveurs ("flavors"). D'autres sont des morceaux de la même application qui peuvent être installés séparemment. 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.
$ sudo pkg_add -v screen-4.0.3p0
parsing screen-4.0.3p0
installed /etc/screenrc from /usr/local/share/examples/screen/screenrc | 71%
screen-4.0.3p0: complete
Dans cet exemple l'option -v a été utilisé pour obtenir une sortie plus bavarde. Cet option n'est pas nécessaire mais elle est utile pour deboguer et a été utilisée ici pour donner un peu plus de perspicacité dans ce que pkg_add(1) est entrain de faire. Notez le message mentionnant /etc/screenrc. Spécifier plusieurs fois l'option -v produira une sortie encore plus bavarde.
$ sudo pkg_add -i screen
Ambiguous: screen could be screen-4.0.3p0 screen-4.0.3p0-shm screen-4.0.3p0-static
Choose one package
0: <None>
1: screen-4.0.3p0
2: screen-4.0.3p0-shm
3: screen-4.0.3p0-static
Your choice: 1
screen-4.0.3p0: complete
Pour certains paquetages, des informations additionnelles importantes vous serons 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. Considerez 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
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érént à 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/4.1/packages/`machine -a`/screen-4.0.3p0.tgz
screen-4.0.3p0: complete
Dans cet exemple l'option -v n'a pas été utilisée donc seulement les messages necéssaires 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écedemment (ou une ancienne version de celui-ci), pkg_add(1) ne re-écrira pas les fichiers de configuration qui ont été modifiés. A 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.3p0
parsing screen-4.0.3p0
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.3p0: complete
$ 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.
Pour résoudre ce type de conflit, vous devez découvrir quoi installer dans l'ordre afin d'obtenir les bibliothèques necéssaires sur votre système. Il y a plusieurs choses à vérifier :
$ 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.3p0 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 ou se trouve un paquetage qui doit être installé), pkg_info(1) donnera plus d'informations détaillées sur ce paquetage spécifique.
Disons que vous avez une vieille version de unzip installée avant de mettre à jour cette machine de OpenBSD 4.0 à 4.1. Maintenant vous pouvez simplement mettre à jour vers le nouveau paquetage 4.1 comme suit :
$ sudo pkg_add -u unzip
unzip-5.52 (extracting): complete
unzip-5.51 (deleting): complete
unzip-5.52 (installing): complete
Clean shared items: complete
Invoquer pkg_add(1) avec l'option -u et sans nom de paquetage va juste 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.
Si vous aviez un fichier de configuration appartenant à la vieille version que vous avez modifié, il sera laissé intacte 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.
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.3p0: 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.3p0) seulement si une ambiguité 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 si ils ont été modifiés. Au lieu de cela il vous en informera comme suit :
$ sudo pkg_delete screen
screen-4.0.3p0: complete
Clean shared items: complete
--- screen-4.0.3p0 -------------------
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.
Veuillez vous référer à la page des paquetages stables pour obtenir des informations au sujet des paquetages mis à jour et des mises à jour importantes de la branche -stable. Il est à noter que les paquetages mis à jour sont seulement disponibles pour les plates-formes i386 et amd64. Pour les autres plates-formes, vous avez besoin d'utiliser la branche -stable de l'arbre des ports et de compiler les sources.
Si vous voulez reçevoir les annonces de sécurité relatives aux logiciels dans les paquetages et le système des ports, vous pouvez souscrire à la liste de diffusion ports-security.
Les noms des paquetages sont toujours changés dans le cas d'une mise à jour du paquetage, pour supprimer tous risques de confusion entre le paquetage d'une révision et le paquetage corrigé d'un bogue. Ce changement de nom doit avoir un numéro de version supérieur ou, dans le cas ou le numéro de version reste inchangé, un suffixe pN est ajouté, ou N+1 représente le nombre de fois que ce paquetage a été modifié.
$ sudo pkg_add screen-4.0.3p0
screen-4.0.3p0: complete 7%
Adjusting md5 for /usr/local/info/screen.info-3 from 49fb3fe1cc3a3b0057518459811b6dac to 3b9c7811244fb9f8d83bb27d3a0f60d8
/usr/sbin/pkg_add: Installation of screen-4.0.3p0 failed , partial installation recorded as partial-screen-4.0.3p0
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 surement des paquetages mélangés avec d'autres logiciels installés à partir des sources.
NOTE IMPORTANTE : L'arbre de ports est destiné aux utilisateurs avançés. Tout le monde est encouragé à utiliser les paquetages binaires pre-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.
En dehors du Makefile, chaque port contient aussi au moins ce qui suit :
Toutes ces informations sont contenus dans une hiérarchie de répertoires sous /usr/ports. Cette hiérarchie contient trois sous-répertoires spéciaux :
Quand un utilisateur éxecute 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. C'est l'un des sous-répertoires du répertoire principal du port, dans ce cas il est identifié par son préfixe "w-", ou un sous-répertoire de ${WRKOBJDIR}, si la variable WRKOBJDIR a été définie (voir Configuration du système des ports).
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écedemment). 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 :
| 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/4.1/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 sure 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 un nombre d'exemples.
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.
SUDO=/usr/bin/sudo
# chgrp -R wsrc /usr/ports
# find /usr/ports -type d -exec chmod g+w {} \;
USE_SYSTRACE=Yes
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 :
WRKOBJDIR=/usr/obj/ports
DISTDIR=/usr/distfiles
PKGREPOSITORYBASE=/usr/packages
$ cd /usr/ports
$ make search key=rsnapshot
Port: rsnapshot-1.2.9
Path: net/rsnapshot
Info: remote filesystem snapshot utility
Maint: Sigfred Haversen
Index: net
L-deps:
B-deps: :net/rsync
R-deps: :net/rsync
Archs: any
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ée, 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ée pour être utilisé dans l'infrastructure des ports. Le port de sqlports inclus 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) le paquetage de sqlports, et dans ce cas, le paquetage de sqlite3 sera démarré. Un session d'exemple peut 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>
$ 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 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 appelera pkg_add(1) avec l'option -r.
Note : Les grosses applications nécessitent une quantité importante de ressources système pour être construite. 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 :
$ make clean
===> Cleaning for rsnapshot-1.2.9
$ make clean=depends
===> Cleaning for rsync-2.6.9
===> Cleaning for rsnapshot-1.2.9
$ make clean=dist
===> Cleaning for rsnapshot-1.2.9
===> Dist cleaning for rsnapshot-1.2.9
$ make clean=flavors
$ make uninstall
===> Deinstalling for rsnapshot-1.2.9
rsnapshot-1.2.9: complete
Clean shared items: complete
$ 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
$ make clean=package
===> Cleaning for rsnapshot-1.2.9
rm -f /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz
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 un saveur "static", qui contruira 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.
Chaque saveur d'un port aura son propre répertoire de travail durant sa 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
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. 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é : Vous emploierez des sous-paquetages quand vous avez besoin seulement d'une partie d'une certaine application, pas de l'application en entier. Cependant, il est très probable que le sous-paquetage que vous recherchez existe, et soit prêt à être cherché et installé depuis votre miroir FTP le plus proche.
Pour afficher les différents sous-paquetages disponibles pour un port, utilisez
$ make show=MULTI_PACKAGES
$ 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.
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-security pour reçevoir les annonces de sécurité relatives aux logiciels dans l'arbre des ports.
Bien evidemment, 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.
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 entetes 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.
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éressent et ce qu'ils peuvent tester dans leur environnement. Vos donations peuvent faire la différence pour le test des ports sur plus de plates-formes.
Quelques ports isolés peuvent traîner derrière les versions traditionnelles pour cette raison. La collection des ports peut avoir une version de retard d'un programme de Janvier pendant qu'une nouvelle version du programme a été livrée par ces développeurs en mai trois mois plus tard. Souvent c'est une décision réfléchie; la nouvelle version peut avoir des problémes sur OpenBSD que le mainteneur essaye de corriger, ou alors ils ont fait une version plus mauvaise que la version précédente : OpenBSD peut avoir différents buts que les autres principaux développeurs dans d'autres projets, qui quelquefois résulte dans une fonctionnalité et un désign ou un choix d'implémentation qui est indésirable du point de vue des développeurs de OpenBSD. La mise à jour peut également être remise à plus tard parce que la nouvelle version n'est pas considérée 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 qui est le mainteneur). Si vous pouvez nous aider avec ceci, tout ira pour le mieux.
Vous pouvez aider. Voyez pour créer votre propre port. Il y a de la documentation disponible dans : Construction d'un port OpenBSD. 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 reçevoir 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.
Plus de réponses à cette question peuvent aussi être trouvées dans la FAQ 1.
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. Des 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. Un exemple courant est CVSup, un outil communement utilisé pour suivre l'arbre des ports de OpenBSD. Pour installer CVSup sur un système modérement rapide avec une bonne connexion Internet cela prend environ dix secondes -- le temps requis pour télécharger et désarchiver un unique fichier de paquetage de 779Ko. En contraste, construire CVSup sur la même machine des sources est une tache énorme, qui requiert beaucoup d'outils et de "bootstrapper" un compilateur, prenant au moins un heure et demi sur la même machine. D'autres applications comme 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 :
$ cd /usr/ports/archivers/unzip
$ make show=MAINTAINER
Alternativement, si 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 :
$ mkdir ~/portslogs
$ cd /usr/ports/archivers/unzip
$ make clean install 2>&1 | /usr/ports/infrastructure/build/portslogger \
~/portslogs
Alternativement, vous pouvez
[FAQ Index] [Section 14 - Configuration des disques]
![[back]](../../images/back.gif){kind=small}
www@openbsd.org