Subversion Repositories svn LFS-FR

Compare Revisions

Ignore whitespace Rev 582 → Rev 583

/trunk/lfs/chapter04/addinguser.xml
8,20 → 8,20
<?dbhtml filename="addinguser.html"?>
 
<para>Lorsque vous êtes connecté en tant qu'utilisateur
<emphasis>root</emphasis>, faire une simple erreur peut endommager voire
dévaster votre système. Donc, nous recommandons de construire les paquets
dans ce chapitre en tant qu'utilisateur non privilégié. Vous pouvez bien sûr
utiliser votre propre nom d'utilisateur mais, pour faciliter l'établissement
d'un environnement de travail propre, créez un nouvel utilisateur
<emphasis>root</emphasis>, une seule erreur peut endommager, voire
dévaster votre système. Du coup, nous vous recommandons de construire les paquets
de ce chapitre en tant qu'utilisateur non privilégié. Vous pouvez bien sûr
utiliser votre propre nom d'utilisateur, mais pour vous assurer un
environnement de travail propre, il est plus sûr de créer un nouvel utilisateur
nommé <emphasis>lfs</emphasis> comme membre d'un nouveau groupe
<emphasis>lfs</emphasis> et utilisez-le lors du processus d'installation.
En tant que <emphasis>root</emphasis>, lancez les commandes suivantes pour créer
<emphasis>lfs</emphasis> et de l'utiliser lors du processus d'installation.
En tant que <emphasis>root</emphasis>, exécutez les commandes suivantes pour créer
le nouvel utilisateur&nbsp;:</para>
 
<screen><userinput>groupadd lfs
useradd -s /bin/bash -g lfs -m -k /dev/null lfs</userinput></screen>
 
<para>Voici la signification des options en ligne de commande&nbsp;:</para>
<para>Voici la signification des options de la ligne de commande&nbsp;:</para>
 
<variablelist>
<varlistentry>
44,9 → 44,9
 
<varlistentry>
<term><parameter>-k /dev/null</parameter></term>
<listitem><para>Ce paramètre empêche tout copie possible de fichiers provenant
<listitem><para>Ce paramètre empêche la copie de fichiers provenant
du répertoire squelette (par défaut, <filename
class="directory">/etc/skel</filename>) en modifiant son emplacement par le
class="directory">/etc/skel</filename>) en le remplaçant par le
périphérique spécial null.</para></listitem>
</varlistentry>
 
59,26 → 59,25
 
<para>Pour vous connecter en tant qu'utilisateur <emphasis>lfs</emphasis> (et
non pas de passer à l'utilisateur <emphasis>lfs</emphasis> alors que vous êtes
connecté en tant que <emphasis>root</emphasis>, ce qui ne requiert pas de mot
de passe pour l'utilisateur <emphasis>lfs</emphasis>), donnez un mot de passe à
connecté en tant que <emphasis>root</emphasis>, ce qui ne requiert pas que
<emphasis>lfs</emphasis> ait un mot de passe), donnez un mot de passe à
<emphasis>lfs</emphasis>&nbsp;:</para>
 
<screen role="nodump"><userinput>passwd lfs</userinput></screen>
 
<para>Donnez-lui un accès complet à <filename
class="directory">$LFS/tools</filename> en indiquant que
<emphasis>lfs</emphasis> est le propriétaire du répertoire&nbsp;:</para>
class="directory">$LFS/tools</filename> en le désignant
comme propriétaire du répertoire&nbsp;:</para>
 
<screen><userinput>chown -v lfs $LFS/tools</userinput></screen>
 
<para>Si un répertoire de travail séparé a été créé comme suggéré, faites
que l'utilisateur <emphasis>lfs</emphasis> soit aussi le propriétaire de ce
répertoire&nbsp;:</para>
<para>Si vous avez créé un répertoire de travail séparé comme suggéré, faites
de même avec ce répertoire&nbsp;:</para>
 
<screen><userinput>chown -v lfs $LFS/sources</userinput></screen>
 
<para>Ensuite, connectez-vous en tant que <emphasis>lfs</emphasis>. Ceci peut
se faire via une console virtuelle, avec le gestionnaire d'affichage ou avec
<para>Ensuite, connectez-vous en tant que <emphasis>lfs</emphasis>. Vous pouvez le faire
via une console virtuelle, avec un gestionnaire d'affichage, ou avec
la commande suivante de substitution d'utilisateur&nbsp;:</para>
 
<screen><userinput>su - lfs</userinput></screen>
85,7 → 84,7
 
<para>Le <quote><command>-</command></quote> indique à <command>su</command> de
lancer un shell de connexion. La différence entre un shell de connexion et un
autre se trouve dans la page man <filename>bash(1)</filename> et dans
autre est décrite dans la page man <filename>bash(1)</filename>, et par
<command>info bash</command>.</para>
 
</sect1>
/trunk/lfs/chapter04/aboutsbus.xml
9,34 → 9,34
<?dbhtml filename="aboutsbus.html"?>
 
<para>Beaucoup de personnes souhaitent savoir combien de temps la compilation
et l'installation de chaque paquet va prendre. Mais Linux from Scratch est
et l'installation de chaque paquet va prendre. Mais, Linux from Scratch est
construit sur tant de systèmes différents qu'il est impossible de donner des
temps précis. Le plus gros paquet (Glibc) prendra approximativement vingt
minutes sur les systèmes les plus rapides mais pourrait prendre environ trois
jours sur les moins rapides. Au lieu de donner les temps constatés, l'unité
de construction standard (<emphasis>Standard Binutils Unit</emphasis>) est
utilisée.</para>
temps universels. Le plus gros paquet (Glibc) prendra approximativement vingt
minutes sur les systèmes les plus rapides mais pourrait prendre jusqu'à trois
jours sur les moins rapides. Au lieu d'indiquer des temps en minutes, on les donnera en nombre d'unités
de standard de construction (<emphasis>Standard Build Unit</emphasis>).
</para>
 
<para>La mesure SBU fonctionne ainsi. Le premier paquet lié statiquement,
que vous compilez dans ce livre, est Binutils lors du <xref
<para>La mesure SBU fonctionne ainsi. Le premier paquet
que vous compilerez dans ce livre est Binutils, dans le <xref
linkend="chapter-temporary-tools"/>. Le temps que prend la compilation de ce
paquet est ce que nous appelons <quote>SBU</quote>. Tous les autres temps
de compilation sont exprimés relativement à ce temps.</para>
paquet est ce que nous appelerons <quote>SBU</quote>. Tous les autres temps
de compilation seront exprimés relativement à ce temps.</para>
 
<para>Par exemple, considérez un paquet spécifique dont le temps de compilation
correspond à 4,5&nbsp;SBU. Ceci signifie que s'il vous a fallu 10 minutes pour
compiler et installer la première passe de Binutils, alors vous savez que cela prendra
<para>Par exemple, considérez un paquet dont le temps de compilation
est de 4,5&nbsp;SBU. Ceci signifie que s'il vous a fallu 10 minutes pour
compiler et installer la première passe de Binutils, alors vous aurez besoin d'
environ 45 minutes pour construire ce paquet. Heureusement, la plupart des
temps de construction sont bien plus courts que celui de Binutils.</para>
 
<para>En général, les SBU ne sont pas vraiment précis car ils dépendent de trop
de facteurs, dont la version de GCC sur votre machine hôte. Notez que les SBU
sont encore moins précis sur les machines multi-processeurs (SMP). Ils sont
fournis ici pour donner une estimation du temps nécessaire pour installer un
paquetage mais ces nombres peuvent varier de plusieurs dizaines de minutes dans
de facteurs, dont la version de GCC que vous employez. Notez que les SBU
sont encore moins précis sur les machines multi-processeurs (SMP). Ils ne sont
qu'une estimation du temps nécessaire à l'installation d'un
paquetage, et la durée effective peut varier de plusieurs dizaines de minutes dans
certains cas.</para>
 
<para>Si vous souhaitez voir des chronométrages réels pour des machines
<para>Si vous souhaitez voir des durées réelles pour des machines
spécifiques, nous recommandons la page d'accueil de <quote>The LinuxFromScratch
SBU</quote> sur <ulink url="&lfs-root;~bdubbs/"/>.</para>
 
/trunk/lfs/chapter04/abouttestsuites.xml
8,46 → 8,46
<title>À propos des suites de tests</title>
<?dbhtml filename="abouttestsuites.html"?>
 
<para>La plupart des paquets disposent d'une suite de tests. Lancer cette suite
<para>La plupart des paquets disposent d'une suite de tests. Exécuter cette suite
de tests pour un paquet nouvellement construit est généralement une bonne idée
car cela peut apporter une vérification comme quoi tout a été compilé
car cela confirme que tout a été compilé
correctement. Une suite de tests réussissant l'ensemble des vérifications prouve
généralement que le paquet fonctionne à peu près comme le développeur en
avait l'intention. Néanmoins, cela ne garantit pas que le paquet ne contient pas
généralement que le paquet fonctionne comme le développeur l'a désiré.
Néanmoins, cela ne garantit pas que le paquet ne contient pas
de bogues.</para>
 
<para>Certaines des suites de tests sont plus importantes que d'autres. Par
exemple, les suites de tests des paquets formant le c&oelig;ur de l'ensemble des
outils (GCC, Binutils et Glibc, la bibliothèque C) sont de la plus grande
<para>Certaines suites de tests sont plus importantes que d'autres. Par
exemple, les suites de tests des paquets formant le c&oelig;ur de la chaîne de
compilation (GCC, Binutils, et Glibc -la bibliothèque C- ) sont de la plus haute
importance étant donné leur rôle central dans un système fonctionnel. Les suites
de tests pour GCC et Glibc peuvent prendre beaucoup de temps pour se terminer,
spécialement sur du matériel lent, mais ces tests sont nécessaires.</para>
spécialement sur du matériel lent, mais elles sont nécessaires.</para>
 
<note><para>L'expérience nous a montré qu'il y a peu à gagner en lançant ces
suites de tests au <xref linkend="chapter-temporary-tools"/>. Il n'y a pas
d'échappatoire au fait que le système hôte exerce toujours une influence sur
les tests dans ce chapitre, occasionnant fréquemment des échecs étonnants et
suites de tests au <xref linkend="chapter-temporary-tools"/>. Il n'est pas possible
de se soustraire à l'influence exercée par le système hôte lors des
tests de ce chapitre, occasionnant fréquemment des échecs étonnants et
inexplicables. Comme les outils construits dans le <xref
linkend="chapter-temporary-tools"/> sont temporaires et éventuellement
supprimés, nous recommandons au lecteur habituel de ce livre de ne pas
lancer les suites de tests dans le <xref linkend="chapter-temporary-tools"/>
pour l'utilisateur de base. Les instructions de lancement de ces suites de tests
linkend="chapter-temporary-tools"/> sont temporaires et ultérieurement
supprimés, nous recommandons à l'utilisateur standard de ne pas
lancer les suites de tests dans ce chapître.
Les instructions pour lancer ces suites de test
sont fournies pour les testeurs et les développeurs mais elles sont réellement
optionnelles pour tous les autres.</para></note>
optionnelles pour toutes les autres personnes.</para></note>
 
<para>Un problème commun lors du lancement des suites de test pour
<para>Un problème courant lors de l'exécution des suites de test de
Binutils et GCC est de manquer de pseudo-terminaux (PTY). Le
symptôme est un nombre inhabituellement haut de tests ayant échoués. Ceci peut
arriver pour un certain nombre de raisons. La plus raisonnable est que le
symptôme est un nombre élevé de tests ayant échoués. Plusieurs causes sont
possibles, mais la plus raisonnable est que le
système hôte ne dispose pas d'un système de fichiers <systemitem
class="filesystem">devpts</systemitem> file configuré correctement. Ce problème
est discuté avec plus de détails dans le <xref
class="filesystem">devpts</systemitem> configuré correctement. Ce problème
est discuté plus en détails dans le <xref
linkend="chapter-temporary-tools"/>.</para>
 
<para>Quelquefois, les suites de tests des paquets échoueront mais pour des
raisons dont les développeurs sont conscients et qu'ils ont estimées non critiques.
Consultez les traces situées dans <ulink url="&test-results;"/> pour vérifier si
ces échecs sont attendus. Ce site est valide pour tous les tests effectués dans
<para>Quelques fois, les suites de test des paquets échoueront pour des
raisons dont les développeurs sont conscients mais qu'ils n'ont pas estimées critiques.
Consultez les traces situées sur <ulink url="&test-results;"/> pour vérifier si
ces échecs sont attendus. Ce site s'applique à tous les tests effectués dans
ce livre.</para>
 
</sect1>
/trunk/lfs/chapter04/creatingtoolsdir.xml
9,15 → 9,15
 
<para>Tous les programmes compilés dans le <xref
linkend="chapter-temporary-tools"/> seront installés dans <filename
class="directory">$LFS/tools</filename> pour les tenir séparés des programmes
class="directory">$LFS/tools</filename> pour les séparer des programmes
compilés dans le <xref linkend="chapter-building-system"/>. Les programmes
compilés ici sont seulement des outils temporaires et ne prendront pas part
au système LFS final. En les conservant dans un répertoire séparé, nous
pourrons facilement les supprimer plus tard. Ceci nous aide aussi à les
empêcher de finir dans les répertoires de production de votre hôte (facile à
compilés ici ne sont que des outils temporaires et ne prendront pas part
au système LFS final. En les plaçant dans un répertoire distinct, nous
pourrons facilement les supprimer plus tard. Ceci évite également qu'ils ne s'installent
dans l'arborescence de l'hôte (facile à
faire par accident dans le <xref linkend="chapter-temporary-tools"/>).</para>
 
<para>Créez le répertoire requis en lançant la commande suivante
<para>Créez ce répertoire en lançant la commande suivante
en tant qu'utilisateur <emphasis>root</emphasis>&nbsp;:</para>
 
<screen><userinput>mkdir -v $LFS/tools</userinput></screen>
25,19 → 25,19
<para>La prochaine étape consiste en la création du lien symbolique
<filename class="symlink">/tools</filename> sur votre système
<emphasis>hôte</emphasis>. Il pointera vers le répertoire que vous venez de
créer sur la partition LFS. Lancez cette commande en tant
créer sur la partition LFS. Exécutez cette commande en tant
qu'utilisateur <emphasis>root</emphasis>&nbsp;:</para>
 
<screen><userinput>ln -sv $LFS/tools /</userinput></screen>
 
<note><para>La commande ci-dessus est correcte. La commande
<command>ln</command> a quelques variations syntaxiques, assurez-vous de
<command>ln</command> a quelques variations syntaxiques, assurez-vous donc de
vérifier <command>info coreutils ln</command> et la page man
<filename>ln(1)</filename> avant de rapporter ce que vous pensez être une
erreur.</para></note>
 
<para>Le lien symbolique créé nous permet de compiler notre ensemble d'outils de
façon à ce qu'il se réfère à <filename>/tools</filename>, ce qui signifie que le
façon à ce qu'il se réfère toujours à <filename>/tools</filename>, ce qui signifie que le
compilateur, l'assembleur et l'éditeur de liens fonctionneront tous dans ce
chapitre (alors que nous utilisons toujours quelques outils provenant de l'hôte)
et dans le suivant (lorsque nous serons en <quote>chroot</quote> sur la
/trunk/lfs/chapter04/settingenviron.xml
8,7 → 8,7
<title>Configurer l'environnement</title>
<?dbhtml filename="settingenvironment.html"?>
 
<para>Configurez un bon environnement de travail en créant deux nouveaux
<para>Définissez un bon environnement de travail en créant deux nouveaux
fichiers de démarrage pour le shell <command>bash</command>. En étant connecté
en tant qu'utilisateur <emphasis>lfs</emphasis>, lancez la commande suivante
pour créer un nouveau <filename>.bash_profile</filename>&nbsp;:</para>
20,15 → 20,14
<para>Lorsque vous êtes connecté en tant que <emphasis>lfs</emphasis>, le shell
initial est habituellement un shell de <emphasis>connexion</emphasis> qui lit
le fichier <filename>/etc/profile</filename> de l'hôte (contenant probablement
quelques configurations et variables d'environnement) et puis
quelques paramètrages et variables d'environnement), puis
<filename>.bash_profile</filename>. La commande <command>exec env
-i.../bin/bash</command> dans le fichier <filename>.bash_profile</filename>
remplace le shell en cours avec un nouveau ayant un environnement complètement
vide sauf pour les variables <envar>HOME</envar>, <envar>TERM</envar> et
<envar>PS1</envar>. Ceci nous assure qu'aucune variable d'environnement non
souhaitée et potentiellement dangereuse, provenant du système hôte, ne
parvienne dans l'environnement de construction. La technique utilisée ici
s'assure de ce but d'environnement propre.</para>
remplace le shell en cours par un nouveau avec un environnement entièrement
vide, à l'exception des variables <envar>HOME</envar>, <envar>TERM</envar> et
<envar>PS1</envar>. Cette technique nous assure un environnement prore en empêchant
les variables d'environnement du système hôte de s'inviter dans le système LFS, au
risque d'y faire des dégats.</para>
 
<para>La nouvelle instance du shell est un shell <emphasis>sans
connexion</emphasis>, qui ne lit donc pas les fichiers
46,41 → 45,41
EOF</userinput></screen>
 
<para>La commande <command>set +h</command> désactive la fonction de hachage de
<command>bash</command>. D'habitude, le hachage est une fonctionnalité utile.
<command>bash</command> utilise une table de hachage pour se rappeler le chemin
complet des fichiers exécutables pour éviter d'avoir à chercher dans
<envar>PATH</envar> à chaque fois qu'il doit trouver le même exécutable.
Néanmoins, les nouveaux outils devraient être utilisés dès leur installation.
En désactivant la fonction de hachage, le shell cherchera en permanence dans
<envar>PATH</envar> lorsqu'un programme doit être exécuté. Ainsi, le shell
trouvera les nouveaux outils compilés dans <filename
class="directory">$LFS/tools</filename> dès qu'ils sont disponibles et sans se
rappeler de la version précédente du même programme mais dans un autre
emplacement.</para>
<command>bash</command>. D'habitude, le hachage est une fonctionnalité utile que
<command>bash</command> utilise pour se souvenir du chemin d'accès
aux fichiers exécutables, évitant ainsi de reparcourir le
<envar>PATH</envar> quand un exécutable est lancé une seconde fois.
Cependant, nous voulons utiliser les nouveaux outils dès leur installation.
En désactivant la fonction de hachage, le shell parcourt le
<envar>PATH</envar> à chaque appel d'un programme. Ainsi, le shell
utilisera les nouveaux outils présents dans <filename
class="directory">$LFS/tools</filename> au fur et à mesure de leur apparition, au lieu de
réutiliser sans cesse les versions originales de ces programmes dont la fonction de hachage
garderait la trace.</para>
 
<para>Configurer le masque de création de fichier (umask) à 022 nous assure que
les nouveaux fichiers et répertoires créés sont modifiables uniquement par
leurs propriétaires mais lisibles et exécutables par tout le monde (en
<para>Attribuer la valeur 022 au masque de création de fichier (umask) nous assure que
les nouveaux fichiers et répertoires créés ne seront modifiables que par
leurs propriétaires, mais lisibles et exécutables par tout le monde (en
supposant que les modes par défaut sont utilisés par l'appel système open(2),
les nouveaux fichiers finiront avec les droits 644 et les répertoires avec
755).</para>
les droits 755).</para>
 
<para>La variable <envar>LFS</envar> devrait être configurée avec le point de
<para>La variable <envar>LFS</envar> devrait pointer sur le point de
montage choisi.</para>
 
<para>La variable <envar>LC_ALL</envar> contrôle la localisation de certains
programmes, faisant que leurs messages suivent les conventions d'un pays
programmes, adaptant leurs messages aux conventions du pays
spécifié. Si le système hôte utilise une version de Glibc plus ancienne que la
2.2.4, avoir <envar>LC_ALL</envar> initialisé à quelque chose d'autre que
2.2.4, avoir <envar>LC_ALL</envar> initialisée à quelque chose d'autre que
<quote>POSIX</quote> ou <quote>C</quote> (pendant ce chapitre) pourrait poser
des problèmes si vous quittez l'environnement chroot et souhaitez y retourner
plus tard. Initialiser <envar>LC_ALL</envar> à <quote>POSIX</quote> ou
<quote>C</quote> (les deux sont équivalents) nous assure que tout fonctionnera
comme attendu dans l'environnement chroot.</para>
comme prévu dans l'environnement chroot.</para>
 
<para>En plaçant <filename class="directory">/tools/bin</filename> au début du
<envar>PATH</envar> standard, tous les programmes installées dans le <xref
linkend="chapter-temporary-tools"/> sont récupérés par le shell immédiatement
<envar>PATH</envar> standard, tous les programmes installées dans <xref
linkend="chapter-temporary-tools"/> sont utilisés par le shell immédiatement
après leur installation. Ceci, combiné avec la désactivation du hachage, limite
le risque que d'anciens programmes de l'hôte soient utilisés alors que les mêmes
programmes sont disponibles depuis l'environnement du chapitre 5.</para>
87,8 → 86,8
 
<beginpage/>
 
<para>Enfin, pour avoir un environnement complètement préparé pour la
construction des outils temporaires, récupérez le source du profile de
<para>Enfin, pour terminer la préparation de l'environnement en vue de la
construction des outils temporaires, chargez le profil de
l'utilisateur tout juste créé&nbsp;:</para>
 
<screen><userinput>source ~/.bash_profile</userinput></screen>
/trunk/lfs/chapter04/aboutlfs.xml
8,7 → 8,7
<?dbhtml filename="aboutlfs.html"?>
 
<para>Tout au long de ce livre, la variable d'environnement <envar>LFS</envar>
sera utilisée de nombreuses fois. Il est vital que cette variable soit toujours
sera utilisée de nombreuses fois. Il est vitale que cette variable soit toujours
définie. Elle doit pointer vers le point de montage choisi pour la partition
LFS. Vérifiez que votre variable <envar>LFS</envar> est correctement configurée
avec&nbsp;:</para>
15,22 → 15,22
 
<screen role="nodump"><userinput>echo $LFS</userinput></screen>
 
<para>Assurez-vous que la sortie affiche le chemin vers le point de
<para>Assurez-vous que le résultat soit bien le chemin vers le point de
montage de la partition LFS, c'est-à-dire <filename
class="directory">/mnt/lfs</filename> si l'exemple fourni a été suivi. Si
cet affichage est mauvais, vous pouvez toujours initialiser la variable
ce n'est pas le cas, vous pouvez initialiser la variable
avec&nbsp;:</para>
 
<screen role="nodump"><userinput>export LFS=/mnt/lfs</userinput></screen>
 
<para>Avoir cette variable initialisée est tout à votre bénéfice car des
<para>Avoir cette variable initialisée est intéressant car des
commandes telles que <userinput>mkdir $LFS/tools</userinput> peuvent être
saisies de façon littérale. Votre shell remplacera <quote>$LFS</quote> par
<quote>/mnt/lfs</quote> (ou par le chemin avec lequel vous avez initialisé la
saisies litéralement. Votre shell remplacera <quote>$LFS</quote> par
<quote>/mnt/lfs</quote> (ou par ce que vous avez placez dans la
variable) lorsqu'il exécutera la ligne de commande.</para>
 
<para>N'oubliez pas de vérifier que <envar>$LFS</envar> est initialisé à chaque
fois que vous entrez dans l'environnement (par exemple, avec <quote>su</quote>
pour <emphasis>root</emphasis> ou un autre utilisateur).</para>
fois que vous ré-entrez dans l'environnement de travail (par exemple, lorsque vous faites un <quote>su</quote>
vers <emphasis>root</emphasis> ou un autre utilisateur).</para>
 
</sect1>