[OpenBSD]

[Index de La FAQ] [Section 4 - Guide d'Installation] [Section 6 - Mise en place du réseau]

5 - Construire le Système à partir des Sources


Table des matières



5.1 - Les Saveurs ("Flavors") d'OpenBSD

Il existe trois "saveurs" d'OpenBSD : Schématiquement, le développement de ces versions ressemble à ceci :
       ,------o-----------o----X                    5.1 Stable
       |      .           .
       |      .    ,------o---------o----X          5.2 Stable
       |      .    |      .         .
       |      .    |      .    ,----o----------o--> 5.3 Stable
       |      .    |      .    |    .          .
       |      .    |      .    |    .    ,-----o--> 5.4 Stable
       |      .    |      .    |    .    |     .
       |      .    |      .    |    .    |     .
 -->5.1Rel----->5.2Rel----->5.3Rel----->5.4Rel----> Current

          Temps --->

-Current: La version courante pour laquelle le développement est réalisé, et qui deviendra la prochaine -release d'OpenBSD. Tous les six mois, lorsqu'une version d'OpenBSD est révisée, -current est taguée, et devient -release : un point gelé dans l'histoire de l'arbre des sources. Chaque -release demeure inchangée; c'est pour cela qu'on la trouve sur les CDs et serveurs FTP.

-Stable est basée sur -release, et est une branche du chemin de développement principal d'OpenBSD. Quand des corrections très importantes sont faites sur -current, elles sont "backportées" (intégrées) aux branches -stable; à cause de cela, -stable est aussi connue sous le nom de branche patch. Dans l'illustration ci-dessus, la ligne verticale en pointillés symbolise les corrections de bogues incorporées aux branches -stable. Vous remarquerez aussi dans l'exemple ci-dessus que la branche 5.1-stable a été supprimée à la sortie de 5.3-release, et que la branche 5.2-stable a été supprimée à la sortie de 5.4-release -- les anciennes versions sont typiquement supportées durant deux "releases" au maximum. Le support d'anciennes versions nécessite des ressources et du temps; et alors que nous pourrions vouloir plutôt fournir un support continu pour les anciennes versions, nous préférerons nous concentrer sur les nouvelles fonctionnalités. La branche -stable est, par conception, très facile à construire à partir de -release de la même version (c'est-à-dire en allant de 5.4-release vers 5.4-stable).

La branche -stable est -release à laquelle on a ajouté les correctifs listés dans la page des errata. Habituellement, le fonctionnement de -stable est le même que celui de -release sur laquelle elle est basée. Si les pages de manuel doivent être modifiées, il est très probable que ces modifications ne fassent pas partie de -stable. En d'autres termes, le support de nouveaux périphériques ne sera PAS ajouté à - stable.

Il est utile de préciser que le nom "-stable" ne signifie pas pour autant que -current est instable ou moins robuste en production. Plutôt que, l'API (comment les programmes dialoguent avec l'OS) et les fonctionnalités de -current changent et évoluent, alors qu'au niveau des APIs et au niveau opérationnel de -stable ce sont les mêmes sur la version sur laquelle ils sont basés, et vous n'aurez pas à apprendre à nouveau votre système, à changer des fichiers de configuration ou à ajouter de nouvelles applications à celui-ci.

En fait, notre préoccupation étant de faire continuellement évoluer OpenBSD, le but avoué est de rendre -current plus fiable, plus sécurisé, et bien sûr offrant de meilleurs outils que -stable. Tout simplement, la "meilleure" version d'OpenBSD est -current.

La plupart des utilisateurs devraient utiliser -stable ou -release. Cela dit, plusieurs personnes utilisent -current sur des systèmes en production, et il est important que les personnes fassent cela pour identifier des bogues et tester les nouvelles fonctionnalités. Cependant, si vous ne savez pas comment décrire, diagnostiquer et gérer proprement un problème, ne vous dites pas (ou à quelqu'un d'autre) que vous être entrain d'"aider le projet" en utilisant -current. "Ça ne marche pas !" n'est pas un rapport de bogue utile. "Les changements récents dans le pilote pciide ont brisé la compatibilité avec mon interface IDE basée sur Slugchip, ci-joint le dmesg d'un système fonctionnel et un système ne fonctionnant pas..." peut être un rapport utile.

Des fois, les utilisateurs "normaux" veulent disposer des derniers développements et utiliser -current. La raison la plus commune de faire cela est que l'utilisateur possède un périphérique qui n'est pas supporté par -release (et donc, par -stable non plus), ou qu'il souhaite utiliser une nouvelle fonctionnalité de -current. Dans ce cas, soit l'utilisateur utilise -current soit il n'utilise pas le périphérique, et utiliser -current est peut-être l'option la plus logique. Cependant, il ne faut pas espérer que les développeurs vous tiennent la main.

Snapshots

Entre les versions formelles d'OpenBSD, des snapshots sont mis à disposition sur les sites FTP. Comme leur nom l'indique, ce sont des images du code dans l'arborescence à l'instant où le créateur de l'image a pris une copie du code pour une plate-forme donnée. Il est possible (et bien heureusement peu probable) que vous rencontriez des bugs dans les snapshots, c'est la raison pour laquelle ils sont compilés et distribués. Si vous trouvez un bug dans un snapshot récent, assurez-vous qu'il est reporté.

Si vous souhaitez utiliser -current, un snapshot récent est tout ce dont vous aurez besoin, et mettre à jour un snapshot est un point de départ nécessaire avant de tenter de compiler -current depuis les sources.

Parfois, on demande s'il y a un moyen d'obtenir une copie exacte du code qui a servi à construire un snapshot. La réponse est non. Primo, il n'y a aucun intérêt. Secundo, les snapshots sont construits selon le souhait des développeurs, lorsque le planning le permet, et lorsque des ressources sont disponibles. Sur les plates-formes rapides, il est possible de créer plusieurs snapshots en un jour. Sur les plates-formes lentes, la création d'un snapshot peut durer une semaine ou plus. Fournir des balises ou des marques dans l'arborescence des sources pour chaque snapshot peut s'avérer peu pratique. Tertio, les snapshots contiennent souvent du code expérimental non encore soumis dans l'arborescence

Mise à jour majeure vs. mise à jour mineure

Il existe deux types de mises à jour sous OpenBSD : des mises à jour majeures et des mises à jour mineures. Il existe des différences notables entre ces deux types de mises à jour que nous allons tâcher d'expliquer ci-après.

Une mise à jour majeure consiste à installer une nouvelle version d'OpenBSD, qui inclut généralement de nouvelles fonctionnalités. Par exemple, le passage d'une version 5.3 à une version 5.4 ou la mise à jour d'un snapshot du 12 juin avec un snapshot du 24 juin sont considérés comme mises à jour majeures. Lors d'une mise à jour majeure, vous devez typiquement consulter Suivre la version de développement "-current" ou le Guide de Mise à niveau d'OpenBSD (lors du passage d'une version à une plus récente) pour effectuer les modifications nécessaires au bon fonctionnement de la nouvelle version d'OpenBSD.
Une mise à jour mineure consiste à appliquer des correctifs à un système afin d'améliorer son fonctionnement SANS modification des fonctionnalités de base ou de la compatibilité binaire. Ceci est généralement effectué en suivant le processus d'Application des correctifs sous OpenBSD ou en suivant la procédure décrite dans le document intitulé Maintenir son système à niveau par rapport à -stable. Quand vous effectuez une mise à jour mineure, votre système passe d'un état -release à un état -stable (ou -release corrigé) de la même version. Par exemple, de 5.2-release à 5.2-stable. Vous pouvez ensuite effectuer une nouvelle mise à jour mineure vers un -stable plus récent de la même version. Le processus de mise à jour est généralement sans conséquence étant donné que les fichiers /etc ou d'autres configurations système n'ont pas besoin d'être modifiés.

Ainsi, vous pouvez installer un système (tel que 5.2-release) à partir du CD, puis vous pourrez le mettre à jour un certain nombre de fois en 5.2-stable et par la suite effectuer une mise à jour majeure vers 5.3-release, puis vers 5.3-stable, 5.4-release, et ainsi de suite.

Garder les Composants Synchronisés

Il est important de comprendre qu'OpenBSD est un Système d'Exploitation, et il faut le prendre en tant que tel et non pas comme un noyau entouré d'un ensemble d'outils. Vous devez vous assurer que votre noyau, l'"userland" (les utilitaires et fichiers complétant le noyau) et l'arborescence des ports sont synchronisés, autrement des choses désagréables peuvent arriver. Dit autrement (vu que les gens continuent à commettre les mêmes erreurs), vous ne pouvez pas utiliser des ports tout neufs sur un système datant d'il y a un mois, ou reconstruire un noyau à partir de -current et espérer qu'il fonctionne correctement avec un userland -release. Oui, cela veut dire que vous aurez besoin d'effectuer une mise à jour majeure de votre système si vous voulez utiliser un nouveau programme qui a été rajouté aujourd'hui à l'arborescence des ports. OpenBSD n'a malheureusement que des ressources limitées.

Il faut aussi comprendre que le processus de mise à jour majeure est uniquement supporté dans une seule direction uniquement : de l'ancien au nouveau, et de -stable vers -current. Vous ne pouvez pas utiliser 5.4-current (ou un snapshot), puis décider que c'est trop dangereux, et revenir vers 5.4-stable. Vous ne pouvez compter que sur vous-même si vous choisissez un autre chemin que celui, supporté, consistant à réinstaller votre système proprement. Vous ne devez espérer aucune aide de la part de l'équipe de développement OpenBSD.

Oui, cela veut dire que vous devez réfléchir avant d'utiliser -current.

5.2 - Pourquoi devrais-je compiler mon système depuis les sources ?

En fait, il y a de fortes chances pour que vous n'en ayez pas besoin.

Voici quelques raisons pour NE PAS compiler votre systèmes depuis les sources :

Voici quelques raisons d'avoir besoin de compiler depuis les sources :

L'équipe OpenBSD réalise fréquemment des instantanés basés sur le code de -current pour toutes les plates-formes. Dans la plupart des cas, cela vous suffira pour utiliser -current.

La raison la plus courante de compiler depuis les sources est de suivre la branche -stable, pour laquelle la compilation depuis les sources est la seule issue supportée.

Si vous compilez -current des sources, il est HAUTEMENT recommandé de le faire d'une machine dont vous avez accès à la console. Il y a des moments dans le processus de développement où des incohérences entre votre nouveau noyau et votre ancien userland rendra le système inaccessible via le réseau. Cela n'est pas un problème quand c'est compilé correctement de -stable.

5.3 - Compilation d'OpenBSD depuis les sources

5.3.1 - Aperçu du processus de compilation

La compilation d'un système OpenBSD depuis les sources implique un certain nombre d'étapes : Il y a deux étapes supplémentaires que certains utilisateurs pourraient vouloir réaliser, ceci dépend de la raison de la compilation et de la présence ou non de X :

5.3.2 - Installer ou mettre à niveau depuis les binaires les plus récents

La première étape dans la compilation depuis les sources est de s'assurer d'avoir le binaire le plus récent installé. Utilisez ce tableau afin de savoir où vous en êtes, où vous voulez aller, et avec quel binaire commencer :

Vous êtes au But Mise à niveau binaire vers ensuite ...
Ancienne -release Nouvelle release Dernière release C'est fait !
-release -stable Dernière release Récupérer & compiler -stable
Ancienne -stable -stable Nouvelle release Récupérer & compiler -stable
-release -current Dernier instantané Récupérer (optionnel) & compiler -current
Ancienne -current -current Dernier instantané Récupérer (optionnel) & compiler -current

Il est recommandé d'installer le binaire via l'option "Upgrade" du média d'installation. Si ce n'est pas possible, vous pouvez aussi décompacter les binaires comme décrit ici. Vous pouvez faire le processus complet de mise à niveau sans soucis, incluant la création d'utilisateurs ou d'autres changements de répertoires de /etc.

5.3.3 - Téléchargement des sources appropriées

La source d'OpenBSD est gérée en utilisant le système de contrôle de versions CVS, et cvs(1) est utilisé pour récupérer les sources désirées sur votre machine locale, à des fins de compilation. Ceci peut être réalisé en utilisant le serveur AnonCVS (une machine proposant une copie du dépôt CVS utilisé par le projet OpenBSD) et ce publiquement, ou depuis une archive locale que vous maintenez en utilisant les programmes CVSync ou rsync disponibles dans les paquetages. Si vous avez plusieurs machines sur lesquelles vous désirez maintenir le code source, vous devriez trouver utile d'avoir un dépôt CVS local, créé et maintenu en utilisant CVSync ou rsync.

Après avoir décidé quel Serveur AnonCVS vous allez utiliser, vous devez effectuer un "checkout" (récupération) de l'arbre des sources, que vous maintiendrez par la suite en lançant des "updates" (mises à jour), afin de récupérer les fichiers les plus récents dans votre arbre local.

La commande CVS(1) dispose de nombreuses options, certaines d'entre elles sont requises afin de récupérer et de mettre à jour un arbre. Les autres commandes peuvent résulter en un arbre cassé. Le fait de comprendre et de suivre les directions est ici important.

Suivi de -current

Dans ce cas, nous supposons que vous utilisez un serveur AnonCVS publique, anoncvs@anoncvs.example.org:/cvs. Nous supposons également que vous utilisez le shell sh(1), vous devrez dans le cas contraire ajuster certaines commandes.

Pour récupérer un arbre des sources CVS de -current, vous pouvez utiliser la commande suivante :

    # cd /usr
    # export CVSROOT=anoncvs@anoncvs.example.org:/cvs
    # cvs -d$CVSROOT checkout -P src

Une fois l'arbre récupéré, vous pourrez plus tard le mettre à jour avec :

    # cd /usr
    # export CVSROOT=anoncvs@anoncvs.example.org:/cvs
    # cvs -d$CVSROOT up -Pd
Suivi de -stable
Si vous souhaitez récupérer une "branche" alternative de l'arbre, comme la branche -stable, vous devez utiliser le modificateur "-r" :
    # cd /usr
    # export CVSROOT=anoncvs@anoncvs.example.org:/cvs
    # cvs -d$CVSROOT checkout -rOPENBSD_5_4 -P src
Ceci aura pour effet de récupérer les fichiers sources de la branche OPENBSD_5_4, aussi connue sous le nom de "Branche patchée" ou "-stable". Vous pourrez mettre à jour le code de façon similaire :
    # cd /usr/src
    # export CVSROOT=anoncvs@anoncvs.example.org:/cvs
    # cvs -d$CVSROOT up -rOPENBSD_5_4 -Pd
CVS est vraiment agréable car il permet de suivre une balise dans les fichiers récupérés, vous n'avez ainsi pas à vous rappeler de la partie "-rOPENBSD_5_4" de la ligne de commande, ceci sera mémorisé jusqu'à ce que vous l'effaciez ou en spécifiez un autre via l'option "-A" de "update". Cependant, il est probablement plus correct de fournir trop d'infos que pas assez sur vos lignes de commande CVS.

L'arbre "src" étant le seul à avoir été montré jusqu'à présent, vous pouvez faire les mêmes étapes pour "xenocara" et "ports". Toutes les parties d'OpenBSD devant être en synchronisation, tous les arbres utilisés devraient être mis à jour en même temps. Vous pouvez allier plusieurs récupérations sur une seule ligne (-stable est montré) avec :

    # export CVSROOT=anoncvs@anoncvs.example.org:/cvs
    # cd /usr
    # cvs -d$CVSROOT checkout -rOPENBSD_5_4 -P src ports xenocara
Cependant, les mises à jour doivent être faites répertoire par répertoire.

À ce niveau, que vous ayez suivi -stable ou -current vous devriez avoir un arbre des sources correct. Soyez attentif à ce que vous récupérez -- vous pourriez compiler -current en pensant compiler -stable.

Pré-chargement de l'arbre des sources : src.tar.gz, sys.tar.gz

Au lieu de télécharger l'arbre des sources dans sa totalité à partir d'un serveur AnonCVS, vous pouvez le "pré-charger" à partir des fichiers des sources se trouvant sur le CD d'OpenBSD ou sur les serveurs FTP. Vous économiseriez ainsi beaucoup de temps et de bande passante. Ceci est particulièrement vrai si vous utilisez -stable, étant donné le peu de différences entre cette version et -release.

Pour extraire l'arbre des sources à partir du CD vers /usr/src (en supposant que le CD est monté dans /mnt) :

    # cd /usr/src; tar xzf /mnt/src.tar.gz
    # cd /usr; tar xzf /mnt/xenocara.tar.gz
    # cd /usr; tar xzf /mnt/ports.tar.gz
Les fichiers sources téléchargeables depuis les serveurs FTP sont séparés en deux fichiers pour minimiser le temps nécessaire à leur téléchargement pour les personnes souhaitant travailler avec telle ou telle partie de l'arbre uniquement. Ces deux fichiers sont sys.tar.gz, qui contient les fichiers utilisés pour créer le noyau, et src.tar.gz qui contient toutes les autres applications userland, hormis l'arbre des ports et les sources X11. Cependant, et de manière générale, vous aurez besoin des deux. En supposant que vous les ayez téléchargé src.tar.gz et sys.tar.gz dans /usr :
    # cd /usr/src
    # tar xzf ../sys.tar.gz
    # tar xzf ../src.tar.gz
    # cd /usr
    # tar xzf xenocara.tar.gz
    # tar xzf ports.tar.gz

L'extraction de toutes les parties de l'arbre source n'est pas obligatoire mais si on souhaite garder un système cohérent, il est conseillé de les extraire toutes.

Astuces CVS courantes

Comme indiqué précédemment, certaines options sont obligatoires afin d'obtenir un arbre src d'OpenBSD valide. L'option "-P" ci-dessus est l'une d'entre elle : elle "prune" (efface) les répertoires vides. Avec les années, des répertoires ont été créés puis supprimés, et les noms de ces répertoires sont parfois utilisés actuellement pour des fichiers. Sans l'option "-P", votre arbre fraîchement récupéré NE compilera PAS.

Même chose pour l'option -d sur une commande 'update' -- elle crée les nouveaux répertoires ayant pu être ajoutés au dépôt depuis votre dernier "checkout". Pour réussir une mise à jour, il faut absolument utiliser les options -Pd.

Les utilisateurs de CVS expérimentés auront pu se demander pourquoi le CVSROOT est précisé et utilisé dans cet exemple, alors que cvs(1) enregistre la situation du serveur dans l'arbre ainsi obtenu. Ceci est correct, cependant, un utilisateur devra souvent outrepasser le serveur enregistré, et de nombreuses personnes recommandent de toujours spécifier le dépôt à utiliser. Il est aussi à noter que si la variable d'environnement CVSROOT peut être utilisée directement par cvs(1), elle est utilisée uniquement si rien ne vient la remplacer, et la spécification de la ligne de commande est prépondérante.

Il est souvent utile d'utiliser un .cvsrc dans votre répertoire home afin de spécifier les options par défaut. Un fichier .cvsrc d'exemple :

    $ more ~/.cvsrc
    cvs -q -danoncvs@anoncvs.example.org:/cvs
    diff -up
    update -Pd
    checkout -P
Ce fichier ordonnera à cvs(1) d'utiliser le serveur anoncvs@anoncvs.example.org:/cvs, supprimant les sorties souvent inutiles ("-q" pour "quiet", tranquille) pour toutes les opérations, la commande "cvs up" utilisant par défaut -Pd, la commande "cvs diff" réalisant par défaut des "diffs unifiés" suite à l'option "-u", et un "cvs checkout" utilisera l'option "-P". Tandis que cela est confortable, si vous oubliez que ce fichier existe, ou si vous essayez de lancer ces commandes auxquelles vous êtes habitué sans ce fichier, vous rencontrerez des problèmes.

L'arbre des sources est constitué d'un grand nombre de petits fichiers. Il est donc conseillé d'activer soft updates sur la partition où se trouve cet arbre afin d'améliorer significativement les performances.

5.3.4 - Compilation du noyau

Nous supposerons que vous désirez construire un noyau standard (GENERIC ou GENERIC.MP). Normalement, c'est ce que vous devriez faire. N'essayez pas de construire un noyau personnalisé si vous ne maîtrisez pas le processus de compilation standard.

Évidemment, le noyau est un composant TRÈS dépendant du matériel du système. Les sources du noyau sont dans le répertoire /usr/src/sys. Certaines parties du code du noyau d'OpenBSD sont utilisées sans distinction de plate-forme, alors que d'autres sont très spécifiques à un processeur ou une architecture. Si vous regardez dans le répertoire /usr/src/sys/arch/, vous verrez certaines choses quelque peu intrigantes -- par exemple, il y a des répertoires mac68k, m68k et mvme68k. Dans ce cas, les systèmes mvme68k et mac68k utiliseront tous deux le même processeur, mais les machines sur lesquelles ils sont basés sont très différentes, et elles demandent ainsi un noyau très différent (il y a bien plus de choses qu'un processeur dans un ordinateur !). Cependant, certaines parties du noyau sont communes, elles demeurent dans le répertoire m68k. Si vous compilez simplement un noyau, les répertoires de l'architecture de base comme m68k ne sont pas un soucis, vous devriez travailler uniquement avec les répertoires de "l'architecture composant", comme mvme68k.

Les noyaux compilés sont basés sur les fichiers de configuration du noyau, qui se trouvent dans le répertoire /usr/src/sys/arch/<votre plate-forme>/conf. La compilation du noyau consiste à l'utilisation du programme config(8) pour créer et peupler un répertoire compile, qui se terminera dans /usr/src/sys/arch/<votre plate-forme>/compile/<nom du noyau>. Pour cet exemple, nous supposerons que vous utilisez la plate-forme i386 :

# cd /usr/src/sys/arch/i386/conf
# config GENERIC
# cd ../compile/GENERIC
# make clean && make
    [...beaucoup de sortie...]
# make install
Remplacez "i386" sur la première ligne par le nom de votre plate-forme. La commande machine(1) peut vous donner le nom de la plate-forme sur laquelle vous êtes afin de pouvoir utiliser "cd /usr/src/sys/arch/`machine`/conf" à la place de la première ligne.

À ce stade, redémarrez votre machine afin d'activer le nouveau noyau. Notez que le nouveau noyau devrait être lancé avant l'étape suivante, ce que vous savez si vous avez suivi les explications ci-dessus sur la mise à niveau vers les instantanés les plus récents. Parfois, les APIs changent cependant, et l'ancien noyau sera dans l'incapacité de lancer de nouvelles applications, mais les nouveaux noyaux supportent en général les applications plus anciennes.

Remarquez que vous pouvez compiler un noyau sans accès root, mais vous devez être root pour pouvoir l'installer.

5.3.5 - Compilation de l'userland

Il y a une marche à suivre spécifique afin que cela fonctionne, sans quoi vous vous amuserez à essayer de comprendre d'où les problèmes viennent.

5.4 - Compilation d'une Révision

Qu'est-ce qu'une "release" (révision), et pourquoi voudrais-je en créer une ?

Une "release" est le jeu de fichiers complet pouvant être utilisé pour installer OpenBSD sur un ordinateur. Si vous n'avez qu'une seule machine sous OpenBSD, vous n'avez pas de réelle motivation à construire une release, le processus ci-dessus vous apportant tout ce dont vous avez besoin. Un exemple d'utilisation du processus de release pourrait être de compiler une -stable sur une machine puissante, et de faire une release installable sur tous vos ordinateurs.

Le processus de release utilise les binaires créés dans le répertoire /usr/obj lors du processus ci-dessus, vous devez donc accomplir celui-ci au préalable, et rien ne doit perturber le répertoire /usr/obj. Ceci peut être un problème si vous utilisez un disque mémoire pour /usr/obj avec de petites performances lors du processus de compilation, vous ne voudrez pas redémarrer l'ordinateur entre les étapes de compilations et de "release" !

Le processus de release requiert deux répertoires de travail, appelés DESTDIR et RELEASEDIR. Tous les fichiers faisant partie d'une installation OpenBSD "propre" seront copiés à l'endroit correct au sein de DESTDIR. Ils seront tar(1)és puis placés dans RELEASEDIR. À la fin du processus, RELEASEDIR arborera la release OpenBSD intégralement. Le processus de release utilisera aussi /mnt, ce point ne doit donc pas être utilisé par autre chose pendant le processus de release. A titre d'exemple, nous utiliserons DESTDIR à /usr/dest et RELEASEDIR à /usr/rel.

Le processus de release utilisera un utilitaire, crunchgen(8), qui sert à créer un exécutable unique composé de plusieurs binaires. Le nom qui l'invoque détermine quel composant binaire est utilisé. C'est un peu comme si plusieurs fichiers de programmes individuels étaient concentrés sur un ramdisk noyau qui existe sur les disquettes et autres médias d'installation.

Vous devez avoir les privilèges root pour créer une release.

Faire une release

Définissons nos variables d'environnement DESTDIR et RELEASEDIR :
# export DESTDIR=/usr/dest
# export RELEASEDIR=/usr/rel
Nettoyons DESTDIR et créons le répertoire :
# test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}.old && rm -rf ${DESTDIR}.old &
# mkdir -p ${DESTDIR} ${RELEASEDIR}
RELEASEDIR ne doit pas forcément être vide lors du lancement du processus mais, cependant, s'il y a des changement dans les fichiers de la release ou dans leurs noms, les anciens fichiers seront conservés. Vous voudrez ainsi certainement effacer ce répertoire.

Passons à présent à la release elle-même :

# cd /usr/src/etc
# make release
Une fois la release compilée, il peut être bon de la vérifier afin d'être sûr que les fichiers tar reflètent bien le contenu de DESTDIR. La sortie de cette étape devrait être très courte :
# cd /usr/src/distrib/sets
# sh checkflist
Vous avez à présent un jeu de fichiers complet et fonctionnel dans RELEASEDIR. Ces fichiers peuvent être utilisés afin d'installer ou de mettre à jour OpenBSD sur d'autres machines.

Les instructions faisant foi sur la création d'une release sont dans release(8).

Remarque : Si vous souhaitez distribuer les fichiers résultants par HTTP pour être utilisables par les scripts de mise à jour ou d'installation, vous devrez ajouter un fichier "index.txt". Ce fichier contient la liste de tous les fichiers constituant votre release fraîchement créée.

# /bin/ls -1 >index.txt
Dès que vous avez une release complète créée, vous pouvez utiliser ces fichiers pour une installation standard ou une mise à jour sur une autre machine, ou si vous mettez à jour une autre machine pour une nouvelle -stable, décompressez simplement les fichiers tar dans le répertoire racine de la machine cible.

5.5 - Compilation de X (Xenocara)

À partir de X.org v7, X est devenu un système à "compilation modulaire", découpant l'arborescence des sources de x.org en plus de trois cents packages plus ou moins indépendants.

Pour simplifier la vie des utilisateurs d'OpenBSD, un procédé de "méta-compilation" nommé Xenocara a été développé. Ce système "reconvertit" X en une seule grosse arborescence pour permettre la compilation en une seule étape. Comme point positif supplémentaire, ce processus de compilation se rapproche bien plus du processus de construction utilisé par le reste d'OpenBSD que les versions précédentes.

Les instructions officielles pour compiler X se trouvent dans le fichier /usr/xenocara/README ainsi que dans release(8).

Obtenir le code source

L'arborescence des sources de xenocara se trouve "habituellement" dans /usr/src/xenocara. Les sources sont stockées dans le module xenocara du CVS. Le checkout se fera donc ainsi :
$ cd /usr
$ cvs -qdanoncvs@anoncvs.example.org:/cvs checkout -P xenocara

Compiler Xenocara

Pour compiler l'arbre standard de xenocara sur OpenBSD, aucun outil externe n'est nécessaire.
# cd /usr/xenocara
# rm -rf /usr/xobj/*
# make bootstrap
# make obj
# make build
Si vous voulez faire des modifications dans le code source, vous aurez probablement besoin d'ajouter plusieurs packages. Les détails sont dans le fichier /usr/xenocara/README.

Création d'une release X

Ceci est similaire au processus de release principal. Après avoir compilé X avec succès, vous définirez DESTDIR et RELEASEDIR, de la même manière qu'évoqué précédemment. RELEASEDIR peut être le même répertoire que la principale RELEASEDIR système, mais DESTDIR sera effacé et reconstruit lors de ce processus. Si cela est fait avec attention, ce n'est pas un problème, mais l'utilisation d'un DESTDIR séparé est plus sûre.

Pour cet exemple, nous utiliserons les DESTDIR et RELEASEDIR comme /usr/dest et /usr/rel, respectivement. Ceci doit être fait après le processus de compilation ci-dessous.

# export DESTDIR=/usr/dest
# export RELEASEDIR=/usr/rel
# test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}- && \
     rm -rf ${DESTDIR}- &
# mkdir -p ${DESTDIR} ${RELEASEDIR}
# make release
Une fois le processus complété, vous aurez un ensemble de fichiers release dans le $RELEASEDIR

5.6 - Pourquoi aurais-je besoin d'un noyau sur mesure ?

En réalité, vous n'en avez très probablement pas besoin.

Un noyau sur mesure est un noyau construit à partir d'un fichier de configuration autre que GENERIC, le fichier de configuration fourni de base. Un noyau sur mesure peut se baser sur du code source -release, -stable ou -current comme c'est le cas pour le noyau GENERIC. Alors que la compilation de votre propre noyau GENERIC est supportée par l'équipe OpenBSD, la compilation de votre propre noyau sur mesure ne l'est pas.

Le fichier de configuration noyau OpenBSD standard (GENERIC) est conçu pour convenir à la plupart des utilisateurs. Bon nombre de personnes ont rendu leur système inopérant en essayant d'optimiser le noyau au lieu d'améliorer son fonctionnement. Il existe certaines personnes qui pensent qu'un noyau et un système d'exploitation doivent être taillés sur mesure pour obtenir des performances optimales. Ceci n'est pas vrai dans le cas d'OpenBSD. Seules les personnes très compétentes avec des applications très particulières doivent penser à faire un noyau et un système sur mesure.

Voici quelques raisons pour lesquelles vous devriez créer un noyau sur mesure :

Voici quelques raisons pour lesquelles vous ne devez pas compiler un noyau sur mesure :

La suppression de pilotes pourrait rendre plus rapide la phase de démarrage système. Cependant, elle peut compliquer la récupération suite à problème matériel. La suppression de pilotes est une tâche très souvent mal réalisée. La suppression de pilotes ne rendra pas votre système plus rapide de manière perceptible même si elle peut produire un noyau plus petit. La suppression des parties liées au débogage et à la vérification d'erreurs peut améliorer les performances, mais rendra impossible l'analyse du système si quelque chose ne fonctionne plus ou pas.

Encore une fois, les développeurs ignorent d'habitude les rapports de bogue relatifs à des noyaux personnalisés, sauf si le problème peut être reproduit avec un noyau GENERIC. Vous aurez été prévenu.

5.7 - Options de configuration du noyau

Nous partons du fait que vous avez lu ci-dessus, et que vous aimez la douleur. Il est aussi supposé que vous avez un but ne pouvant être atteint ni avec Configuration au démarrage (UKC>), ni avec config(8)urer un noyau GENERIC. Si toutes les possibilités sont fausses, vous devriez vous en tenir à utiliser GENERIC. Vraiment.

La création d'un noyau OpenBSD est contrôlée par le biais de fichiers de configuration, se trouvant dans le répertoire /usr/src/sys/arch/<arch>/conf/ par défaut. Toutes les architectures possèdent un fichier, GENERIC, qui peut être utilisé pour générer un noyau OpenBSD standard pour une plate-forme donnée. Il peut aussi y avoir d'autres fichiers de configuration qui peuvent être utilisés pour créer des noyaux avec des objectifs différents tels que la minimisation de l'utilisation de la RAM, les stations de travail "diskless", etc.

Le fichier de configuration est traité par config(8), qui crée et peuple un répertoire de compilation situé sous ../compile. Pour une installation typique, le chemin absolu du répertoire serait situé sous /usr/src/sys/arch/<arch>/compile/. config(8) peut aussi créer un fichier Makefile, et d'autres fichiers requis pour créer avec succès un noyau.

Les options de configuration du noyau sont des options que vous ajoutez à la configuration de votre noyau pour activer certaines caractéristiques dans celui-ci. Ceci vous permet d'avoir exactement le support que vous voulez sans vous encombrer des pilotes inutiles. Il y a une multitude d'options qui vous permettront de personnaliser votre noyau. Veuillez consulter la page de manuel options(4) pour une liste complète des options. Vous pouvez aussi consulter les fichiers d'exemples de configurations qui sont disponibles pour votre architecture.

L'ajout, la suppression, ou la modification d'options dans votre noyau ne doivent être effectués que si vous avez une bonne raison pour le faire ! N'éditez pas le fichier de configuration GENERIC !! La seule configuration du noyau supportée par l'équipe OpenBSD est le noyau GENERIC, la combinaison d'options figurant dans les fichiers /usr/src/sys/arch/<arch>/conf/GENERIC et /usr/src/sys/conf/GENERIC tels que livrés par l'équipe OpenBSD (i.e. non édités). Émettre un rapport de bogue concernant un noyau personnalisé va dans la plupart des cas se résumer à une réponse vous demandant d'essayer de reproduire le problème avec un noyau GENERIC. Les options ne sont pas toutes compatibles entre elles, et plusieurs options sont nécessaires au bon fonctionnement du système. Il n'y a aucune garantie quant au fonctionnement d'un noyau personnalisé que vous avez réussi à compiler. Il n'y a aucune garantie sur le fait qu'un noyau pouvant être "config(8)uré" puisse être compilé.

Vous pouvez voir les fichiers de configuration spécifiques à une plate-forme donnée ici :

Si vous lisez attentivement ces fichiers, vous verrez une ligne comme :

     include "../../../conf/GENERIC"
Cela signifie que l'on fait référence à un autre fichier de configuration. Ce fichier comprend toutes les options qui ne sont pas dépendantes de l'architecture. Donc quand vous créez votre fichier de configuration, soyez sûr de regarder /sys/conf/GENERIC pour voir ce que vous voulez.

Toutes les options ci-dessous doivent être placées dans le fichier de configuration du noyau avec le format :

option      nom
ou
option      nom=valeur 
Par exemple, pour utiliser l'option "DEBUG" dans le noyau, il faut mettre la ligne suivante :
option      DEBUG
Les options dans le noyau OpenBSD sont traduites en tant qu'options du préprocesseur, donc une option telle que DEBUG compilerait les sources avec l'option -DDEBUG. Ce qui est équivalent à placer un #define DEBUG à travers les sources du noyau.

Vous aurez peut-être parfois besoin de désactiver une option précédemment définie dans le fichier "src/sys/conf/GENERIC" typiquement. Bien entendu, vous pouvez modifier une copie de ce fichier, mais une meilleure méthode consiste à utiliser la clause rmoption. Par exemple, si vous souhaitiez vraiment désactiver le débogueur intégré au noyau (non recommandé !), vous ajouteriez la ligne suivante :

 rmoption DDB 
à votre fichier de configuration du noyau. option DDB est définie dans src/sys/conf/GENERIC, mais la ligne rmoption ci-dessus la désactive.

Encore une fois, veuillez consulter options(4) pour plus d'informations concernant les spécificités de ces options. Il est à noter que plusieurs options possèdent leurs propres pages de manuel -- il faut toujours lire toutes les informations disponibles au sujet d'une option avant de l'ajouter ou la supprimer de votre noyau.

Compiler un noyau sur mesure

Dans ce cas, nous compilerons un noyau supportant les cartes série ISA multi-port boca(4). Cette carte n'est pas dans le noyau GENERIC, du fait qu'elle entre en conflit avec d'autres drivers. Il y a deux moyens courants de faire un noyau personnalisé : copier le fichier de configuration GENERIC vers un autre nom et l'éditer, ou créer un fichier "wrapper" qui inclut le noyau standard GENERIC ainsi que toutes les options dont vous avez besoin, et qui ne sont pas dans GENERIC. Dans ce cas, votre fichier "wrapper" pourrait ressembler à :
include "arch/i386/conf/GENERIC"

boca0  at       isa? port 0x100 irq 10     # BOCA 8-port serial cards
com*   at       boca? slave ?
Les deux lignes au regard des cartes boca(4) sont copiées depuis les lignes commentées dans GENERIC, avec l'IRQ ajusté comme requis. L'avantage d'utiliser ce fichier "wrapper" est que les changements imprévus dans GENERIC sont automatiquement mis à jour comme lors de toute mise à jour du code. L'inconvénient est qu'on ne peut supprimer un périphérique (cependant, c'est en général une mauvaise idée).

L'autre moyen de générer un noyau personnalisé est de faire une copie du GENERIC standard, en lui donnant un autre nom, et en l'éditant selon les besoins. L'inconvénient est que les futures mises à jour du fichier de configuration GENERIC devront être fusionnés dans votre copie, ou vous devrez refaire votre fichier de configuration.

Dans un autre événement, après avoir fait votre fichier de configuration personnalisé, utilisez config(8) et construisez le noyau comme documenté ci-dessus.

Les instructions complètes pour la création de votre propre noyau sont dans la page de manuel config(8).

5.8 - Configuration au démarrage

Lorsque vous démarrez votre système il est possible que vous remarquiez que votre noyau trouve vos périphériques mais à la mauvaise IRQ. Et que vous aillez immédiatement besoin de ce périphérique. Sans recompiler votre noyau vous pouvez utiliser la configuration au démarrage de celui-ci. Cela vous permettra de corriger votre problème pour cette fois et uniquement pour cette fois. Si vous redémarrez le système il faudra recommencer la procédure. Il s'agit donc d'une méthode temporaire. Le problème devra être corrigé en utilisant config(8). De plus votre noyau à besoin de l'option BOOT_CONFIG dans la configuration du noyau. Le noyau GENERIC possède cette option.

Une grande partie de ce document peut-être trouvée dans la page de manuel boot_config(8).

Pour démarrer avec UKC (User Kernel Config), il faut spécifier l'option -c au démarrage.

boot> boot hd0a:/bsd -c
ou n'importe quel autre noyau que vous voulez démarrer. L'invite de commandes UKC apparaîtra, et vous pourrez spécifier au noyau les périphériques que vous désirez modifier, ceux que vous voulez activer ou désactiver.

Voici un liste des commandes les plus utilisées dans UKC.

Une fois votre noyau configuré, utilisez quit ou exit et continuez le démarrage. Une fois votre système démarré, vous devriez rendre la modification permanente au niveau de votre binaire du noyau, tel que c'est décrit dans utilisation de config(8) pour changer le binaire du noyau

5.9 - Utilisation de config(8) pour changer le binaire du noyau

Les options -e et -u de config(8) peuvent être très utiles et vous évitent de perdre du temps à recompiler votre noyau. Le drapeau -e vous permet de rentrer en configuration UKC alors que le système fonctionne. Les changements prendront effets au prochain redémarrage. Le drapeau -u permet de voir si des changements ont été effectués au noyau pendant le démarrage, signifiant que vous avez utilisé boot -c pour entrer en configuration UKC.

Les exemples suivants montrent la désactivation des périphériques ep* dans le noyau. Pour plus de sécurité, il est préférable d'utiliser l'option -o qui écrira les changements dans un fichier spécifié. Par exemple : config -e -o bsd.new /bsd écrira les changements dans bsd.new. Les exemples n'utilisent pas l'option -o, mais les changements sont ignorés et ne sont pas écrits dans le binaire du noyau. Pour plus d'informations sur les messages d'erreur et autres avertissements, lisez la page de manuel config(8) .

$ sudo config -e /bsd
WARNING: no output file specified
OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013
    deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Enter 'help' for information
ukc> ?
        help                                Command help list
        add             dev                 Add a device
        base            8|10|16             Base on large numbers
        change          devno|dev           Change device
        disable         attr val|devno|dev  Disable device
        enable          attr val|devno|dev  Enable device
        find            devno|dev           Find device
        list                                List configuration
        lines           count               # of lines per page
        show            [attr [val]]        Show attribute
        exit                                Exit, without saving changes
        quit                                Quit, saving current changes
        timezone        [mins [dst]]        Show/change timezone
        bufcachepercent [number]            Show/change BUFCACHEPERCENT
        nkmempg         [number]            Show/change NKMEMPAGES
ukc> list
  0 video* at uvideo* flags 0x0
  1 audio* at uaudio*|sb0|sb*|gus0|pas0|ess*|wss0|wss*|ym*|eap*|envy*|eso*|sv*|n
eo*|cmpci*|clcs*|clct*|auacer*|auglx*|auich*|auixp*|autri*|auvia*|azalia*|fms*|m
aestro*|esa*|yds*|emu* flags 0x0
  2 midi* at umidi*|sb0|sb*|ym*|mpu*|mpu*|autri*|eap*|envy* flags 0x0
  3 drm* at inteldrm*|radeondrm* flags 0x0
  4 inteldrm* at vga0|vga* flags 0x0
  5 radeondrm* at vga0|vga* flags 0x0
  6 radio* at udsbr*|bktr0|fms* flags 0x0
  7 vscsi0 at root flags 0x0
  8 softraid0 at root flags 0x0
  9 nsphy* at url*|udav*|mos*|axe*|aue*|xe*|ef*|hme*|lii*|bce*|ale*|alc*|age*|jm
e*|et*|nfe*|stge*|vge*|bnx*|bge*|lge*|nge*|msk*|sk*|ste*|se*|sis*|wb*|tl*|vte*|v
r*|pcn*|sf*|ti*|gem*|ne0|ne1|ne2|ne*|ne*|ne*|epic*|sm0|sm*|dc*|dc*|re*|re*|rl*|r
l*|mtd*|fxp*|fxp*|xl*|xl*|ep0|ep*|ep*|ep*|ep*|ep* phy -1 flags 0x0
 10 nsphyter* at url*|udav*|mos*|axe*|aue*|xe*|ef*|hme*|lii*|bce*|ale*|alc*|age*
|jme*|et*|nfe*|stge*|vge*|bnx*|bge*|lge*|nge*|msk*|sk*|ste*|se*|sis*|wb*|tl*|vte
*|vr*|pcn*|sf*|ti*|gem*|ne0|ne1|ne2|ne*|ne*|ne*|epic*|sm0|sm*|dc*|dc*|re*|re*|rl
*|rl*|mtd*|fxp*|fxp*|xl*|xl*|ep0|ep*|ep*|ep*|ep*|ep* phy -1 flags 0x0
[...snip...]
ukc> disable ep
 95 ep* disabled
 96 ep* disabled
281 ep0 disabled
282 ep* disabled
283 ep* disabled
340 ep* disabled
ukc> quit
not forced

Dans l'exemple ci-dessus, tous les périphériques ep* sont désactivés du noyau et ne seront donc pas testés. Dans certaines situations où vous aurez effectué ces changements au démarrage avec UKC et boot -c, il vous faudra les rendre définitifs. Pour ce faire, il faudra utiliser l'option -u. Dans l'exemple suivant, l'ordinateur a été démarré avec UKC et les périphériques wi(4) sont désactivés. Étant donné que les changements fait par boot -c ne sont pas permanents, ceux-ci doivent être écrits sur le disque. Cet exemple montre comment écrire les changements effectués par boot -c dans un nouveau noyau binaire bsd.new.

$ sudo config -e -u -o bsd.new /bsd
OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013
    deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Processing history...
161 wi* disabled
162 wi* disabled
417 wi* disabled
Enter 'help' for information
ukc> quit

5.10 - Obtention d'une sortie plus verbeuse lors du démarrage

L'obtention d'une sortie plus verbeuse peut s'avérer être très utile lors des tentatives de résolution de problème au boot. Si vous avez un problème inhérent à votre disquette de boot et désirez obtenir plus d'informations, redémarrez. À l'arrivée au prompt "boot>", bootez avec l'option -c. Ceci vous permettra d'être dans UKC>, puis de faire :
UKC> verbose
autoconf verbose enabled
UKC> quit

Vous aurez à présent une sortie très verbeuse au démarrage.

5.11 - Problèmes courants, astuces et questions lors de la compilation et de la construction

La plupart du temps, les problèmes lors de la compilation sont causés par le fait de ne pas suivre précisément les indications précédentes. Cependant, il peut exister occasionnellement de véritables problèmes lors de la compilation de -current à partir du snapshot le plus récent mais les erreurs lors de la compilation de -release ou -stable sont presque toujours dues à une erreur de l'utilisateur.

Les problèmes les plus courants sont :

Voici tout de même certains problèmes auxquels vous pourriez être confronté :

5.11.1 - La compilation s'est arrêtée avec une erreur "Signal 11"

La compilation d'OpenBSD et d'autres programmes à partir des sources est une tâche qui sollicite le matériel plus que la plupart des autres opérations, faisant un usage intensif du CPU, du disque et de la mémoire. Par conséquence, si votre matériel a des problèmes, ces derniers apparaîtront plus facilement durant une compilation. Les défaillances "Signal 11" sont typiquement causées par des problèmes matériel, et la plupart du temps à cause de problèmes de mémoire. Mais ces défaillances peuvent aussi causées par le CPU, la carte mère, ou des problèmes de surchauffe. Votre système peut d'ailleurs être stable la plupart du temps et connaître des défaillances lors de la compilation de programmes.

Il est recommandé de réparer ou remplacer les composants à l'origine des défaillances; les problèmes pouvant se manifester sous d'autres formes plus tard. Si vous avez du matériel que vous souhaitez utiliser et qui ne vous pose aucun problème, installez simplement un snapshot ou une "révision".

Pour plus d'informations, consultez la Faq Sig11.

5.11.2 - "make build" échoue en générant un message "cannot open output file snake: is a directory"

Ceci est le résultat de deux erreurs séparées : Il est important de suivre soigneusement les instructions lors de la récupération et de la compilation de votre arbre.

5.11.3 Mon système sans IPv6 ne fonctionne pas !

Oui. Nous vous prions de ne pas faire de modifications au système de base pour lesquelles vous ne comprenez pas toutes les conséquences. Un "petit" changement dans le noyau peut avoir un impact très large sur le reste du système entier. Relisez s'il vous plaît ceci.

5.11.4 - Oops ! J'ai oublié de créer le répertoire /usr/obj avant de commencer !

En faisant un "make build" avant de faire un "make obj", vous devrez en terminer avec les fichiers objets accumulés dans votre répertoire /usr/src. C'est une mauvaise chose. Si vous désirez essayer d'avoir à télécharger l'arbre des sources une nouvelle fois, vous pouvez essayer les manipulations suivantes afin de nettoyer les fichiers objets :
    # cd /usr/src
    # find . -type l -name obj | xargs rm
    # make cleandir
    # rm -rf /usr/obj/*
    # make obj

5.11.5 - Conseil : Placer /usr/obj sur sa propre partition

Si vous compilez souvent, vous trouverez plus rapide de mettre /usr/obj sur sa propre partition. Le bénéfice est simple, il est typiquement plus rapide de :
    # umount /usr/obj
    # newfs VotrePartitionObj
    # mount /usr/obj
que de faire "rm -rf /usr/obj".

5.11.6 - Comment ne pas compiler certaines parties de l'arbre ?

Vous souhaiterez peut-être ne pas compiler certaines parties de l'arbre, typiquement parce que vous l'avez remplacé par une application incluse dans un paquetage, ou parce que vous voulez créer une installation "plus petite" pour diverses raisons. La solution est d'utiliser l'option SKIPDIR de /etc/mk.conf.

Note : il est de ce fait possible de compiler des systèmes cassés. Les résultats de cette option ne sont pas supportés par le projet OpenBSD.

5.11.7 - Où puis-je avoir plus d'informations sur le processus de compilation ?

5.11.8 - Je ne vois aucun snapshot sur le site FTP. Où sont-ils passés ?

Les snapshots peuvent être retirés lorsqu'ils deviennent anciens (ou obsolètes) ou lorsque la sortie d'une -release approche.

5.11.9 - Comment puis-je amorcer sur une nouvelle version du compilateur (gcc)?

Vous devriez vraiment installer le dernier snapshot.

5.11.10 - Quel est le meilleur moyen de mettre à jour /etc, /var, et /dev ?

En tant que politique, les logiciels dans l'arbre OpenBSD ne modifient pas de fichiers dans /etc automatiquement. Cela signifie que les modifications à réaliser incombent toujours à l'administrateur. Les mises à niveau n'y font pas exception. Pour mettre à jour les fichiers dans ces répertoires, déterminez tout d'abord les changements qui ont été opérés sur les fichiers de la base (distribution) et répétez manuellement ces changements.

Par exemple, pour voir les fichiers dans l'arbre qui ont changé récemment, faîtes un :

    # cd /usr/src/etc
    # ls -lt |more

Pour voir tous les changements dans le répertoire /etc entre des versions arbitraires d'OpenBSD, vous pouvez utiliser CVS. Par exemple, pour voir les changements entre 5.3 et 5.4, faites un :

    # cd /usr/src/etc
    # cvs diff -u -rOPENBSD_5_3 -rOPENBSD_5_4
Pour voir les changements entre 5.4 et -current ("HEAD"), utilisez :
    # cd /usr/src/etc
    # cvs diff -u -rOPENBSD_5_4 -rHEAD
Le script /dev/MAKEDEV n'est pas mis à jour automatiquement lors du processus de compilation, mais il est cependant installé comme partie de la mise à jour binaire. En règle générale, c'est une bonne idée que de copier (si besoin est) et de lancer ce script depuis votre arbre des sources lors de la mise à niveau :
    # cd /dev
    # cp /usr/src/etc/etc.`machine`/MAKEDEV ./
    # ./MAKEDEV all

Une fois que vous avez identifié les changements, appliquez à nouveau ceci à votre arbre local, en préservant toute configuration que vous auriez pu faire.

Les changements typiques de /etc à considérer, entre les release concernent :

Ces changements sont résumés dans upgrade54.html (pour aller vers 5.4-release) ou current.html (pour aller vers -current).

5.11.11 - Y a-t-il un moyen facile de faire des changements sur tous les fichiers de la hiérarchie ?

De temps en temps, des fichiers et répertoires sont ajoutés, ou supprimés dans le fichier hierarchy. Aussi, le possesseur de l'information pour les portions du système de fichiers peut changer. Un moyen facile de s'assurer que votre hiérarchie est à jour est d'utiliser l'outil mtree(8).

Tout d'abord, procurez-vous les dernières sources, en faisant :

    # cd /usr/src/etc/mtree
    # install -c -o root -g wheel -m 600 special /etc/mtree
    # install -c -o root -g wheel -m 444 4.4BSD.dist /etc/mtree
    # mtree -qdef /etc/mtree/4.4BSD.dist -p / -u

Votre hiérarchie de fichiers devrait à présent être à jour.

5.11.12 - Puis-je cross-compiler ? Pourquoi pas ?

Les outils de cross-compilation sont présent dans le système, et sont utilisés par les développeurs lors de la création d'un nouveau port. Cependant, ils ne sont pas maintenus pour une utilisation généralisée.

Lorsque les développeurs créent le support d'une nouvelle plate-forme, l'un des premiers gros tests est la compilation native. Compiler le système depuis les sources augmente très fortement la charge de l'OS et de la machine, et permet de voir à quel point le système fonctionne correctement. Pour cette raison, OpenBSD réalise les compilations sur les plates-formes que la compilation concerne, ceci est appelé le "native building". Sans compilation native, il serait bien plus difficile de s'assurer que les différentes plates-formes sont stables et qu'elles ne font pas que booter.

[Index de La FAQ] [Section 4 - Guide d'Installation] [Section 6 - Le réseau]


[back] www@openbsd.org
$OpenBSD: faq5.html,v 1.113 2013/11/03 08:09:59 ajacoutot Exp $