Pour rendre les choses plus faciles à suivre, nous utilisons un certain nombre de conventions tout au long du livre. Voici quelques exemples :
./configure --prefix=/usr
Vous devriez taper ce style de texte exactement comme montré sauf mention contraire dans le texte attenant. Ce style est aussi utilisé pour identifier des commandes en particulier.
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 également utilisé pour afficher des noms de fichiers, par exemple
/boot/grub/grub.conf
Mise en évidence
Ce style de texte est utilisé de différentes manières dans ce livre, mais surtout pour mettre en évidence les points importants ou donner des exemples de ce que l'on peut saisir.
https://www.linuxfromscratch.org/
Ce style de texte est utilisé pour les liens vers des pages qui sont externes au livre, comme les guides pratiques, les emplacements de téléchargement, les 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 sur les lignes suivantes, jusqu'à ce que la séquence de fin de fichier (End Of File, EOF) soit rencontrée. Donc, vous recopierez généralement cette section entière tel quel. Rappelez-vous que le copier-coller est votre ami !
<TEXTE À REMPLACER>
Ce format est utilisé pour intégrer du texte à modifier qui ne devra pas être saisi tel quel ni être copié-collé. Les chevrons 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 du logiciel 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. Rappelez-vous de toujours vérifier les dépendances imbriquées.
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 BLFS correspondantes. Dans ce cas c'est à vous 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 si elle est initialisée 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 » (trois états) : 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 (<>) dans le menu de configuration 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 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élisme = 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 qui utilisent 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 d'échange. 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 vous devrez spécifier -j1 à la commande make. Les paquets qui sont connus pour avoir ces limites sont marqués comme tels dans le texte.