Conventions utilisées dans ce livre

Conventions typographiques

Pour faciliter le suivi des choses, il y a un certain nombre de conventions utilisées tout au long du livre. Ce qui suit sont des 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 si le texte indique le contraire. 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. Ce format est aussi utilisé pour afficher des noms de fichiers, comme /boot/grub/grub.conf

Mise en évidence

Ce style de texte est utilisé dans différents buts dans ce livre. Son but principal est de mettre en évidence les points importants ou de donner un exemple de ce qu'on peut taper.

http://www.linuxfromscratch.org/

Ce format est utilisé pour les liens vers des pages externes. Cela inclut les guides pratiques, les emplacements de téléchargement et des sites web, etc..

SeaMonkey-2.49.4

Ce style de texte est utilisé pour les liens internes vers le livre tels qu'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 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 qui ne devra pas être saisi tel quel et qui ne devra pas être copié-collé. Remarquez que les crochets ne font pas partie du texte mais devraient être remplacés aussi.

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.

Conventions utilisées pour les dépendances des paquets

Quand des paquets sont créés, 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.

Dépendances requises

Ces dépendances sont les paquets prérequis minimum requis pour construire le paquet. Les paquets de LFS et les dépendances requises par d'autres paquets requis sont omis de cette liste.

Dépendances recommandées

Ces dépendances sont celles que les éditeurs de BLFS ont déterminées comme importantes pour donner 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 omis.

Dépendances facultatives

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 non présentes dans 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.

Convention utilisées pour les options de configuration du noyau

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 comme vous voulez
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

Notez que, en fonction d'autres sélections, les signes (<>) peuvent apparaître comme des parenthèses ({}), si l'option ne peut pas être désélectionnée, ou entre tirets (-*- ou -M-), lorsque le choix est imposé. Le texte d'aide à propos d'une option spécifie les autres choix qui sont reliés à cette option, et comment ces autres choix sont initialisés.

Valeurs de SBU dans BLFS

Comme dans LFS, chaque paquet dans BLFS a un temps de construction d'indiqué en Unité de construction Standard (SBU). Ces temps sont relatifs au temps mis pour construire binutils dans LFS et sont destinés à fournir quelques indications sur le 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 quelques cas, longs, les constructions sont lancées et testées sur des systèmes multi-cœur 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. Notez 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 (p.e. tout ce qui utilise meson) ou rust, par défaut tous les cœurs sont utilisés donc des commentaires similaires seront 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, sur certaines machines le temps peut être encore plus grand 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 entrainer 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 l'autre cœur inactif).

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 tel dans le texte.

Last updated on 2018-09-23 17:06:59 +0000