Pour rendre les choses plus faciles à suivre, il y a un certain nombre de conventions utilisées tout au long du livre. Voici quelques exemples :
./configure --prefix=/usr
Ce style de texte est conçu pour être tapé exactement de la même façon qu'il est vu sauf mention contraire dans le texte attenant. Il est aussi utilisé dans les sections d'explications pour identifier les commandes référencées.
install-info: unknown option
`--dir-file=/mnt/lfs/usr/info/dir'Ce style de texte (texte à largeur fixe) montre une sortie d'écran, généralement le résultat de commandes. Il est aussi utilisé pour afficher des noms de fichiers, par exemple
/boot/grub/grub.conf
Mise en évidence
Ce style de texte est utilisé dans différents buts dans ce livre, le principal étant de mettre en évidence les points importants ou de donner des exemples de ce que l'on peut taper.
https://www.linuxfromscratch.org/
Ce style de texte est utilisé pour les liens vers des pages qui sont externes au livre. Cela inclut les guides pratiques, les emplacements de téléchargement et des sites web, etc.
Ce style de texte est utilisé pour les liens internes au livre, comme une autre section décrivant un paquet différent.
cat > $LFS/etc/group << "EOF"
root:x:0:
bin:x:1:
......
EOF
Ce format est utilisé principalement lors de la création de fichiers de configuration. La première commande (en gras) indique au système de créer le fichier
$LFS/etc/groupà partir de ce qui est saisi jusqu'à ce que la séquence de fin de fichier (End Of File) (EOF) soit rencontrée. Donc, cette section entière est généralement saisie de la même façon.
<TEXTE À REMPLACER>
Ce format est utilisé pour intégrer du texte à modifier qui ne devra pas être saisi tel quel ni être copié-collé. Remarquez que les crochets ne font pas partie du texte mais devraient aussi être remplacés.
root
Ce style de texte est utilisé pour indiquer une référence à un utilisateur ou un groupe système spécifique dans les instructions.
Lors de la création de paquets, les auteurs dépendent de travaux antérieurs. Pour pouvoir construire un paquet dans BLFS, ces dépendances doivent être construites avant le paquet désiré. Pour chaque paquet, les paquets prérequis sont listés dans une ou plusieurs sections séparées : requises, recommandées et facultatives.
Ces dépendances sont les paquets prérequis minimum nécessaires pour construire le paquet. Les paquets de LFS et les dépendances requises par d'autres paquets requis sont omis de cette liste.
Ces dépendances sont celles que les éditeurs de BLFS ont déterminées comme importantes pour apporter au paquet des fonctionnalités raisonnables. Les instructions d'installation du paquet considèrent qu'elles sont installées. Si vous ne voulez pas d'un paquet recommandé, vous devrez probablement modifier les instructions pour s’accommoder de ce paquet manquant.
Ces dépendances sont celles que le paquet peut utiliser. L’intégration de dépendances facultatives peut être automatiquement faite par le paquet ou peut demander des instructions supplémentaires qui ne sont pas suggérées par BLFS. Les paquets facultatifs peuvent être listés sans les instructions de BLFS correspondantes. Dans ce cas c'est à l'utilisateur de déterminer les instructions d'installation appropriées.
Certains paquets ont des besoins spécifiques par rapport à la configuration du noyau. Le modèle général est le suivant :
Master section --->
Subsection --->
[*] Required parameter [CONFIG_REQU_PAR]
<*> Required parameter (not as module) [CONFIG_REQU_PAR_NMOD]
<*/M> Required parameter (could be a module) [CONFIG_REQU_PAR_MOD]
<*/M/ > Optional parameter [CONFIG_OPT_PAR]
[ ] Incompatible parameter [CONFIG_INCOMP_PAR]
< > Incompatible parameter (even as module) [CONFIG_INCOMP_PAR_MOD]
[CONFIG_...] sur la droite donne le nom de l'option pour que vous
puissiez facilement vérifier ce qui est initialisé dans votre
fichier config. La signification des
différentes entrées est :
Master section item supérieur du menu Subsection item du sous-menu Required parameter l'option peut être soit « built-in » ou « not selected » : elle doit être sélectionnée Required parameter (not as module) l'option peut être soit « built-in », « module » ou « not selected » : elle doit être sélectionnée comme « built-in » Required parameter (could be a module) l'option peut être soit « built-in », « module » ou « not selected » : elle doit être sélectionnée soit comme « built-in » soit comme « module » Optional parameter rarement utilisé : l'option peut être soit « built-in », « module » ou « not selected » : elle peut être sélectionnée selon vos préférences Incompatible parameter l'option peut être soit « built-in » ou « not selected » : elle ne doit pas être sélectionnée Incompatible parameter (even as module) l'option peut être soit « built-in », « module » ou « not selected » : elle ne doit pas être sélectionnée
Remarquez que, en fonction d'autres sélections, les chevrons (<>) peuvent apparaître comme des accolades ({}) si l'option ne peut pas être désélectionnée ou comme des tirets (-*- ou -M-) lorsque le choix est imposé. Le texte d'aide à propos de l’option spécifie les autres choix qui sont reliés à cette option et comment ces autres choix sont initialisés.
Comme dans LFS, chaque paquet dans BLFS a un temps de construction indiqué en Unité de construction Standard (SBU). Ces temps sont relatifs au temps mis pour construire des binutils dans LFS et sont destinés à fournir un aperçu du temps que va mettre le paquet à se construire. La plupart des temps sont indiqués pour construire le paquet avec un seul processeur ou cœur. Dans certains cas, des constructions longues sont lancées et testées sur des systèmes multicœurs et les temps SBU sont indiqués avec un commentaire tel que « (parallélisation=4) ». Cette valeur indique que le test a été réalisé en utilisant plusieurs cœurs. Remarquez que cela peut augmenter la vitesse de construction sur des systèmes avec le matériel approprié, l'augmentation de vitesse n'est pas linéaire et certaines améliorations dépendent des paquets ou du matériel spécifique utilisé.
Pour les paquets utilisant ninja (par exemple tout ce qui utilise meson) ou rust, tous les cœurs sont utilisés par défaut. Des commentaires similaires seront donc présents sur ces paquets même si le temps de construction est minimal.
Lorsque même une construction parallèle prend plus de 15 SBU, le temps peut être encore plus long sur certaines machines, même lorsque la construction n'utilise pas l'espace de swap. En particulier, différentes micro-architectures construiront des fichier à des vitesses relatives différentes et cela peut entraîner des délais lorsque certaines cibles attendent la création d'un autre fichier. Lorsqu'une grosse construction utilise beaucoup de fichiers C++, les processeurs avec le Multi-threading simultané partageront leurs unités de calcul en virgule flottante et peuvent prendre 45% plus de temps que lorsque quatre cœurs « principaux » sont utilisés (mesuré sur un intel i7 avec taskset et en gardant les autres cœurs inactifs).
Certains paquets ne supportent pas la construction parallèle et l'utilisation de -j1 pour la commande make est requise. Les paquets qui sont connus pour avoir ces limites sont marqués comme tels dans le texte.
Last updated on