Remarques sur la construction de logiciels

Construction de logiciels en tant qu'utilisateur non privilégié (non root)

La règle d'or de l'administration d'un système Unix est de n'utiliser vos super-pouvoirs que si nécessaire. D'où la recommandation de BLFS de construire les logiciels en tant qu'utilisateur non privilégié et de ne devenir l'utilisateur root que lors de l'installation du logiciel. On suit cette philosophie dans tous les paquets du livre. Sauf spécifications contraires, toutes les instructions devraient être exécutées en tant qu'utilisateur non privilégié. Le livre vous conseillera sur les instructions qui ont besoin des privilèges root.

Déballer le logiciel

S'il y a un fichier compressé au format .tar, on le déballe en utilisant une des commandes suivantes :

tar -xvf filename.tar.gz
tar -xvf filename.tgz
tar -xvf filename.tar.Z
tar -xvf filename.tar.bz2

Vous pouvez utiliser aussi une méthode légèrement différente :

bzcat filename.tar.bz2 | tar -xv

Enfin, vous avez parfois besoin de déballer des correctifs qui ne sont généralement pas au format .tar. La meilleure manière de faire cela est de copier le chemin du fichier dans le parent du répertoire de 'construction' puis d'exécuter une des commandes suivantes selon que le fichier est un .gz ou un .bz2 :

gunzip -v patchname.gz
bunzip2 -v patchname.bz2

Vérifier l'intégrité des fichiers en utilisant 'md5sum'

En général, pour vérifier que le fichier téléchargé est authentique et complet, de nombreux mainteneurs de paquets distribuent aussi des sommes md5 des fichiers. Pour vérifier la somme md5 des fichiers téléchargés, téléchargez à la fois le fichier et le fichier md5sum correspondant dans le même répertoire (de préférence à partir d'emplacements différents en ligne) et (en supposant que file.md5sum est le fichier md5sum téléchargé), lancez la commande suivante :

md5sum -c file.md5sum

S'il y a une erreur, elle sera signalée. Remarquez que le livre BLFS comprend les sommes md5 de tous les fichiers sources. Pour utiliser les sommes md5 fournies par BLFS, vous pouvez créer un file.md5sum (mettez les données md5sum et le nom exact du fichier téléchargé sur la même ligne d'un fichier, séparés par un espace blanc), et lancez la commande montrée ci-dessus. Sinon, lancez simplement la commande décrite ci-dessus et comparez la sortie avec les données de somme md5 inscrites dans le livre BLFS.

md5sum <name_of_downloaded_file>

Créer des fichiers journaux pendant l'installation

Pour les gros paquets, il est commode de créer des fichiers journaux plutôt que de dévisager l'écran en espérant récupérer une erreur ou un avertissement particulier. Les fichiers journaux sont aussi utiles pour déboguer et garder des enregistrements. La commande suivante vous permet de créer un journal d'installation. Remplacez <commande> par la commande que vous cherchez à exécuter.

( <command> 2>&1 | tee compile.log && exit $PIPESTATUS )

2>&1 redirige les messages d'erreur vers le même endroit que la sortie standard. La commande tee vous permet de voir la sortie en journalisant les résultats dans un fichier. Les parenthèses autour de la commande exécutent toute la commande dans un sous-shell et, enfin, la commande exit $PIPESTATUS s'assure que c'est bien le résultat de <commande> qui est retourné et pas le résultat de la commande tee.

Utilisation de processeurs multiples

Pour la plupart des systèmes modernes avec des processeurs multiples (ou cœurs) le temps de compilation pour un paquet peut être réduit en effectuant une « construction parallèle » soit en initialisant une variable d'environnement, soit en disant au programme make combien de processeurs sont disponibles. Par exemple, un Core2Duo peut supporter deux processus simultanés avec :

export MAKEFLAGS='-j2'

ou en compilant simplement avec :

make -j2

Généralement le nombre de processus ne doit pas dépasser le nombre de cœurs supportés par le CPU. Pour lister les processeurs de votre système, tapez : grep processor /proc/cpuinfo.

Dans certains cas, l'utilisation de processeurs multiples peut amener dans une sorte de « course » où le succès de la construction dépend de l'ordre des commandes lancées par le programme make. Par exemple, si un exécutable demande un fichier A et un fichier B, en essayant de lier le programme avant qu'un des composants dépendants ne soit disponible, aboutira à un échec. Cela est possible car les développeurs n'ont pas proprement désigné tous les prérequis utiles pour accomplir une étape du Makefile.

Si cela arrive, la meilleure chose à faire est de recommencer la construction avec un seul processeur. En ajoutant « -j1 » à une commande make, cela écrasera l'initialisation similaire dans une variable d'environnement MAKEFLAGS.

Procédures de construction automatique

Il y a des fois où automatiser la construction d'un paquet peut s'avérer utile. Chacun a ses raisons de vouloir automatiser la construction, et chacun le fait par ses propres moyens. Soit en créant des Makefiles, des scripts Bash, des scripts Perl ou simplement une liste de commandes utilisées à copier-coller, sont des méthodes que vous pouvez utiliser pour automatiser la construction de paquets BLFS. Détailler et donner des exemples sur les nombreuses manières d'automatiser la construction de paquets va au-delà des objectifs de cette section. Cette section vous présentera l'utilisation de la redirection de fichiers et de la commande yes pour vous donner des idées sur la façon d'automatiser vos constructions.

Redirection de fichier pour automatiser l'entrée

Il y aura des moments, pendant votre aventure BLFS, où vous tomberez sur un paquet ayant une invite de commande vous demandant des informations. Ces informations peuvent être des détails de configuration, un chemin de répertoire ou une réponse à un accord de licence. Il peut être un challenge d'automatiser la construction de ce paquet. On vous demandera occasionnellement des informations via une série de questions. Une méthode pour automatiser ce type de scénario est de mettre les réponses désirées dans un fichier et d'utiliser la redirection pour que le programme utilise les données du fichier comme réponses aux questions.

La construction du paquet CUPS est un bon exemple de la façon de rediriger un fichier comme entrée aux invites, cela peut vous aider à automatiser la construction. Si vous lancez la suite de test, on vous demande de répondre à une série de questions concernant le type de test à exécuter et si vous avez un programme auxiliaire que le test peut utiliser. Vous pouvez créer un fichier avec vos réponses, une par ligne, et utiliser une commande ressemblant à celle indiquée ci-dessous pour automatiser l'exécution de la suite de tests :

make check < ../cups-1.1.23-testsuite_parms

Cela fait que la suite de tests utilise les réponses du fichier comme entrée pour les questions. Vous pouvez finir par faire des essais et des erreurs pour déterminer le format exact de votre fichier d'entrée pour certaines choses, mais une fois expérimenté et documenté, vous pouvez utiliser cela pour automatiser la construction du paquet.

Utiliser yes pour automatiser l'entrée

Vous n'aurez parfois besoin que de fournir une réponse ou une même réponse à de nombreuses invites. Dans ces cas-là, la commande yes fonctionne vraiment bien. On peut utiliser la commande yes pour fournir une réponse (la même) à une ou plusieurs questions. On peut l'utiliser pour simuler un simple appui sur la touche Entrée, l'entrée de la touche Y ou l'entrée d'une chaîne de texte. La manière la plus facile de montrer son utilisation est peut-être de prendre un exemple.

Créez tout d'abord un petit script Bash en entrant les commandes suivantes :

cat > blfs-yes-test1 << "EOF"
#!/bin/bash

echo -n -e "\n\nPlease type something (or nothing) and press Enter ---> "

read A_STRING

if test "$A_STRING" = ""; then A_STRING="Just the Enter key was pressed"
else A_STRING="You entered '$A_STRING'"
fi

echo -e "\n\n$A_STRING\n\n"
EOF
chmod 755 blfs-yes-test1

Maintenant, lancez le script en lançant ./blfs-yes-test1 depuis la ligne de commande. Il attendra une réponse, qui peut être n'importe quoi (ou rien) suivi de la touche Entrée. Après avoir entré quelque chose, le résultat sera affiché à l'écran. Utilisez maintenant la commande yes pour automatiser l'entrée d'une réponse :

yes | ./blfs-yes-test1

Remarquez que la redirection (le piping) de yes en lui-même vers le script aboutit à ce que y est passé au script. Essayez-la maintenant avec une chaîne de texte :

yes 'This is some text' | ./blfs-yes-test1

La chaîne exacte était utilisée comme réponse au script. Enfin, essayez-la en utilisant une chaîne vide (null) :

yes '' | ./blfs-yes-test1

Remarquez que cela aboutit à ne passer au script que l'appui sur la touche Entrée. C'est utile parfois quand la réponse par défaut à l'invite est suffisante. Cette syntaxe est utilisée dans les instructions de Net-tools pour accepter tous les réglages par défaut à toutes les invites lors de l'étape de configuration. Vous pouvez maintenant supprimer le script de test si vous le désirez.

Redirection de fichiers pour automatiser la sortie

Pour automatiser la construction de certains paquets, surtout ceux qui vous demandent de lire un accord de licence page après page, il faut utiliser une méthode qui évite de devoir appuyer sur une touche pour afficher chaque page. On peut utiliser la redirection de sortie vers un fichier dans ce cas-là pour vous aider à automatiser. La section précédente de cette page a visé à créer des fichiers journaux de la sortie de la construction. La méthode de redirection qui y est décrite utilisait la commande tee pour rediriger la sortie tout en affichant aussi la sortie à l'écran. Ici on ne verra la sortie que dans un fichier.

De nouveau, la manière la plus facile de montrer la technique est de présenter un exemple. Lancez d'abord la commande :

ls -l /usr/bin | more

Bien entendu, vous devrez voir la sortie page par page car on a utilisé le filtre more. Essayez maintenant la même commande, mais en redirigeant cette fois la sortie vers un fichier. Le fichier spécial /dev/null peut être utilisé à la place du fichier indiqué, mais vous n'aurez pas de fichier journal à examiner :

ls -l /usr/bin | more > redirect_test.log 2>&1

Remarquez que cette fois, la commande est immédiatement revenue à l'invite du shell sans devoir parcourir la sortie page par page. Vous pouvez supprimer maintenant le fichier journal.

Le dernier exemple utilisera la commande yes associée à la redirection de sortie pour éviter de naviguer page par page dans la sortie, puis de fournir un y à l'invite. Cette technique peut être utilisée dans les cas où vous devriez, sans elle, naviguer page par page dans la sortie d'un fichier (tel qu'un accord de licence), puis répondre à la question « Acceptez-vous ce qui précède ? ». Pour cet exemple, on a besoin d'un autre petit script Bash :

cat > blfs-yes-test2 << "EOF"
#!/bin/bash

ls -l /usr/bin | more

echo -n -e "\n\nDid you enjoy reading this? (y,n) "

read A_STRING

if test "$A_STRING" = "y"; then A_STRING="You entered the 'y' key"
else A_STRING="You did NOT enter the 'y' key"
fi

echo -e "\n\n$A_STRING\n\n"
EOF
chmod 755 blfs-yes-test2

On peut utiliser ce script pour simuler un programme qui demande que vous lisiez un accord de licence et que vous acceptiez le contrat avant que le programme n'installe quoique ce soit. Lancez d'abord le script sans techniques d'automatisation en exécutant ./blfs-yes-test2.

Maintenant lancez la commande suivante qui utilise les techniques d'automatisation, rendant l'utilisation convenable dans un script de construction automatisé :

yes | ./blfs-yes-test2 > blfs-yes-test2.log 2>&1

Si vous le désirez, lancez tail blfs-yes-test2.log pour voir la fin de la sortie paginée et la confirmation que y a été passé au script. Une fois que cela marche comme cela devrait, vous pouvez supprimer le script et le fichier journal.

Enfin, gardez à l'esprit qu'il y a de nombreux moyens d'automatiser ou de scripter les commandes de construction. Il n'y a pas « une seule » manière de procéder. Votre imagination est la seule limite.

Dépendances

Pour chaque paquet décrit, BLFS liste les dépendances connues. Elles sont listées sous plusieurs en-têtes, dont la signification est la suivante :

Utilisation de paquets sources plus récents

Occasionnellement, dans le livre, vous pourrez être dans la situation ou un paquet ne se construit pas ou ne fonctionne pas correctement. Bien que les éditeurs tentent de faire en sorte que chaque paquet dans le livre se construise et fonctionne correctement, parfois un paquet a été oublié ou n'a pas été testé avec cette version particulière de BLFS.

Si vous découvrez un paquet qui ne se construit pas ou ne fonctionne pas correctement, vous pouvez regarder s'il s'agit de la version la plus récente du paquet. Typiquement, cela signifie que vous irez sur le site web du mainteneur et téléchargerez l'archive la plus récente et tenterez de construire le paquet. Si vous ne pouvez pas déterminer le site web du mainteneur en regardant l'URL de chargement, utilisez Google et cherchez le nom du paquet. Par exemple, dans la barre de recherche de Google tapez: 'nom_du_paquet download' (sans les guillemets) ou quelque chose de similaire. Parfois en tapant : 'nom_du_paquet home page' vous trouverez le site web du mainteneur.

Nettoyage une fois de plus

Dans LFS, le nettoyage des symboles de déboguage a été discuté de nombreuses fois. Pour la construction des paquets BLFS, il n'y a généralement pas d'instructions qui discute de nouveau du nettoyage. Ce n'est probablement pas une bonne idée de nettoyer un exécutable ou une bibliothèque tant qu'ils sont utilisés, alors sortir des environnements de fenêtrage est une bonne idée. Ensuite vous pouvez faire :

find /{,usr/}{bin,lib,sbin} -type f -exec strip --strip-unneeded {} \;

Si vous installez des programmes dans d'autres répertoires tels que /opt ou /usr/local, vous pouvez vouloir nettoyer les fichiers ici aussi.

Pour plus d'information sur le nettoyage, regardez http://www.technovelty.org/linux/stripping-shared-libraries.html.

Fichiers Libtool

Un des effets de bord des paquets qui utilisent Autotools, incluant libtool, est qu'ils créent beaucoup de fichiers avec une extension .la. Ces fichiers ne sont pas utiles dans un environnement LFS. S'il y a des conflits avec des entrées pkconfig, ils peuvent même empêcher des constructions correctes. Vous pouvez songer à effacer ces fichiers périodiquement :

find /lib /usr/lib -not -path "*Image*" -a -name \*.la -delete

La commande suivante efface tous les fichiers .la sauf ceux ayant « Image » dans une partie de leur chemin. Ces fichiers .la sont utilisés par les programmes de ImageMagick. Il peut y avoir d'autres exceptions avec des paquets qui ne sont pas dans BLFS.