Conventions utilisées dans ce livre

Conventions typographique

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.32.1

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 de paquets

Quand des paquets sont créés, les auteurs dépendent de travaux antérieur. Pour pouvoir construire un paquet dans BLFS, ces dépendances doivent être construites avant le paquet désiré. Pour chaque paquet, quelques paquets pré-requis sont listés dans une ou plusieurs sections séparées: Requise, recommandée et facultative.

Dépendances requises

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

Dépendances recommandées

Ces dépendances sont celle que les éditeurs de BLFS ont déterminée comme importante pour donner au paquet des possibilités raisonnalbes. Les instructions d'installation du paqeut considèrent qu'elles sont installées. Si un paquet recommandés n'est pas souhaités, les instructions pourront être modifiées pour s'accomoder de ce paquet oublié.

Dépendances facultatives

Ces dépendances sont celle que le paquet peut utiliser. L'integration de dépendances facultatives peuvent ê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" ou "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 fonctione d'autres sélections, les signes (<>) peuvent apparaître comme des parenthèses ({}), si l'option ne peut pas être déselectionnée, ou entre tirets (-*- ou -M-), alors le choix est imposé. Le texte d'aide à propos d'une option spécifie les autres choix qui sont reliés à cette option, et commet 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 constuire le paquet avec seul processeur ou coeur. Dans quelques cas, longs, les constructions sont lancées et testées sur des systèmes multi-coeur et les temps SBU sont indiqués avec un commentaire tel que 'parallèlisation=4'. Cette valeur indicque que le test a été réalisé en utilisant plusieurs coeur. 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é.

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 maqués comme tel dans le texte.

Last updated on 2007-04-04 21:42:53 +0200