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

install-info: unknown option
`--dir-file=/mnt/lfs/usr/info/dir'

Mise en évidence

http://www.linuxfromscratch.org/

SeaMonkey-2.49.4

cat > $LFS/etc/group << "EOF"
root:x:0:
bin:x:1:
......
EOF

<TEXTE À REMPLACER>

root

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 :

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.