Il n'y a pas de réponse toute faite à cette question, tout dépend de la nature des évolutions. Je viens juste, par exemple, d'exécuter CVSup, et les fichiers suivants ont été modifiés depuis ma dernière recompilation:
src/games/cribbage/instr.c src/games/sail/pl_main.c src/release/sysinstall/config.c src/release/sysinstall/media.c src/share/mk/bsd.port.mk
Il n'y a pas là matière à ce que je recompile mon système. Je vais simplement aller dans les bons sous-répertoires et exécuter make all install, et c'est à peu près tout. Mais s'il y a des évolutions importantes, par exemple sur src/lib/libc/stdlib alors ou je referais, le monde, ou je recompilerais au moins toutes les parties du système qui sont liées statiquement (de même que tout ce que je pourrais avoir ajouté qui serait lié statiquement).
En fin de journée, c'est à vous de voir. Vous préférerez peut-être recompiler votre système tous les quinze jours, et laisser les modifications s'empiler pendant ces quinze jours. Ou bien vous préférez ne recompiler que ce qui a changé et vous faire confiance pour repérer ce qui en dépend.
Et, bien sûr, cela dépend de la fréquence avec laquelle vous voulez faire vos mises à jour, et de si vous êtes sur la branche -stable ou sur la branche -current.
Cela indique généralement un problème matériel. (Re)faire le monde est un bon moyen de mettre votre matériel sous pression, et mettra souvent en évidence des défaillances de la mémoire vive. Cela se manifeste normalement de soi-même: le compilation échoue en recevant de mystérieux signaux.
Vous pouvez vous en assurer si vous relancer la compilation et qu'elle échoue en un endroit différent.
Dans ce cas, vous ne pouvez guère faire autre chose que d'intervertir les différents composants de votre matériel pour déterminer lequel est en cause.
Tout dépend de comment vous voulez refaire le monde par la suite.
/usr/obj contient tous les fichiers objets générés à la compilation. Normalement, une des premières étapes de “make world” est de supprimer ce répertoire et de repartir à zéro. Dans ce cas, conserver ce répertoire /usr/obj après en avoir terminé ne sert pas à grand chose, alors que vous économiseriez pas mal d'espace disque (au jour d'aujourd'hui environ 150Mo).
Néanmoins, si vous savez ce que vous faites, vous pouvez faire en sorte que “make world” saute cette étape. Les reconstructions ultérieures seront beaucoup plus rapides, car la plupart des sources n'auront pas besoin d'être recompilés. Le revers de la médaille est que des problèmes de dépendance subtils peuvent se manifester, provoquant l'échec de votre recompilation de manière étrange. Cela génère fréquemment du bruit sur les listes de diffusion de FreeBSD, quand quelqu'un se plaint que sa mise à jour a échoué, sans réaliser qu'il a tenté de brûler les étapes.
Si vous aimez vivre dangereusement, passez le paramètre “NOCLEAN” à make, comme suit:
Tout dépend de jusqu'où vous êtes allé avant de rencontrer un problème.
En général (mais ce n'est pas une règle absolue) “make world” crée de nouveaux exemplaires des utilitaires de base (comme gcc, et make) et des bibliothèques système. Ces outils et bibliothèques sont ensuite installés. Ils sont ensuite utilisés pour se reconstruire eux-mêmes, et installés de nouveau. Le système entier (y compris maintenant les outils usuels, comme ls ou grep) est ensuite recompilé avec les nouveaux outils et bibliothèques de base.
Si vous en êtes à cette dernière étape, et que vous le savez (parce que vous avez consulté les résultats que vous avez enregistrés) alors vous pouvez (avec une bonne chance de réussite) faire:
qui ne détruira pas les résultats du travail qu'a déjà effectué “make world”.Si vous voyez le message :
-------------------------------------------------------------- Building everything.. --------------------------------------------------------------dans les comptes-rendus de “make world”, cette façon de procéder est probablement sûre.
Si vous ne voyez pas ce message, ou doutez de vous, alors prudence est mère de sûreté, et il vaut mieux tout reprendre depuis le début.
On pose souvent la question sur les listes de diffusion de FreeBSD de savoir s'il est possible de tout compiler sur une seule machine puis d'installer les résultats de cette compilation sur d'autres machines du réseau avec make install.
C'est quelque chose que je n'ai jamais fait, aussi les indications qui suivent m'ont-elles été données par d'autres ou déduites des Makefiles.
La marche exacte à suivre dépend de votre version de FreeBSD.
Note : Vous devrez encore mettre à jour /etc et /dev sur les machines cibles après cette étape.
Dans un message adressé à questions@freebsd.org, Antonio Bemfica a suggéré la méthode suivante:
Date: Thu, 20 Feb 1997 14:05:01 -0400 (AST) From: Antonio Bemfica <bemfica@militzer.me.tuns.ca> To: freebsd-questions@freebsd.org Message-ID: <Pine.BSI.3.94.970220135725.245C-100000@militzer.me.tuns.ca> Josef Karthauser a demandé: > Quelqu'un a-t-il la bonne méthode pour mettre à jour > les machines d'un réseau? D'abord make world, etc... sur votre machine de référence Ensuite, montez / and /usr sur la machine distante: machine_de_référence% mount machine_distante:/ /mnt machine_de_référence% mount machine_distante:/usr /mnt/usr Ensuite, faites make install avec /mnt comme cible: machine_de_référence% make install DESTDIR=/mnt Répétez cela pour chaque machine de votre réseau. Cela marche très bien dans mon cas. Antonio
Ce mécanisme ne fonctionne (autant que je sache) que si vous pouvez écrire sur /usr/src sur le serveur NFS, car ce devait être la cible d'“install” avec la version 2.1.7 et les précédentes.
Entre les versions 2.1.7 et 2.2.0 la cible “reinstall” a été introduite. Vous pouvez utiliser la méthode décrite ci-dessus pour la version 2.1.7, en remplaçant “install” par “reinstall”.
Cela ne demande plus de droits d'écriture sur le répertoire /usr/src du serveur NFS.
Note : Un bogue est apparu avec cette cible entre les versions 1.68 et 1.107 du Makefile, qui impliquait qu'il fallait avoir les droits d'écriture. Ce bogue a été corrigé avant la diffusion de la version 2.2.0 de FreeBSD, mais peut encore poser problème si vous avez un vieux serveur sous -stable de cette époque.
Comme décrit plus haut, les cibles “buildworld” et “installworld” peuvent être employées pour recompiler sur une machine, puis monter par NFS /usr/src et /usr/obj sur la machine distante et y installer le nouveau système.
Passez en mode mono-utilisateur.
Mettez les répertoires /usr/src et /usr/obj sur des systèmes de fichiers et des disques différents. Si possible, installez ces disques sur des contrôleurs différents.
Mieux encore, mettez ces systèmes de fichiers sur plusieurs disques et utilisez “ccd” ("concatenated disk driver" = pilote de disques concaténés).
Ne compilez pas les bibliothèques profilées (mettez “NOPROFILE=true” dans /etc/make.conf). Vous n'en avez certainement pas besoin.
Dans /etc/make.conf, positionnez aussi “CFLAGS” à quelque chose comme “-O -pipe”. L'optimisation “-O2” est bien plus lente, et la différence d'optimisation entre “-O” et “-O2” est en général négligeable. “-pipe” dit au compilateur d'utiliser des tuyaux (“pipes”) à la place de fichiers, ce qui économise des accès disque (mais utilise plus de mémoire).
Donnez l'option -j<n> au compilateur (Si vous avez
une version suffisamment récente de FreeBSD) pour exécuter plusieurs programmes en
parallèle. Cela améliore les choses, que vous ayez une machine mono- ou
multi-processeurs.
Le système de fichiers qui contient /usr/src peut être monté (ou remonté) avec l'option “noatime”. De cette manière, les dates de dernier accès aux fichiers ne sont pas enregistrées sur disque. Vous n'avez de toute façon probablement pas besoin de cette information.
Note : “noatime” existe à partir de la version 2.2.0.
Note : Cet exemple suppose que /usr/src constitue à lui seul un système de fichiers. Si ce n'est pas le cas (s'il fait partie de /usr par exemple) vous devez indiquez le point de montage de ce système de fichiers, et non /usr/src.
Le système de fichiers où se trouve /usr/obj peut être monté (ou remonté) avec l'option “async”. Les écritures sur disque se font alors de façon asynchrone. En d'autres termes, le programme reprend immédiatement la main, mais l'écriture se fait quelques secondes après. Les accès disque sont ainsi groupés, et le gain en performances est spectaculaire.
Note : Rappelez-vous que cette option rend votre système de fichiers plus fragile. Avec cette option, les risques sont accrus qu'en cas de coupure d'alimentation, le système de fichiers soit irrécupérable quand la machine redémarrera.
S'il n'y a que /usr/obj sur ce système de fichiers, ce n'est pas un problème. S'il contient des informations plus sensibles, assurez-vous que vos sauvegardes soient à jour avant d'activer cette option.
Note : Comme auparavant, si /usr/obj ne constitue pas un système de fichiers en soit, remplacez-le dans l'exemple par le nom du point de montage qui convient.
Ce document, ainsi que d'autres peut être téléchargé sur ftp.FreeBSD.org/pub/FreeBSD/doc/.
Pour toutes questions à propos de FreeBSD, lisez la documentation avant de contacter <questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez <doc@FreeBSD.org>.