Faut-il recompiler ses applications ?

Creative Commons License
Cette création est mise à disposition sous un contrat Creative Commons.

L'article original se trouve sur http://ymettier.free.fr/articles_lmag/.

Article publié dans le numéro 17 (mars/avril 2003) de Linux Pratique


Table des matières

1. Introduction
2. Un peu de vocabulaire et de théorie
3. Pourquoi les recompiler?
4. Contraintes et ennuis en vue
5. Comment cela évolue ensuite?
6. Peut-on vivre sans recompiler ses applications?
7. Comment recompiler ses applications
7.1. La compilation
7.2. L'installation
7.3. La désinstallation
8. Veuillez utiliser les paquets de votre distribution
9. Votre distribution bleeding-edge
10. Les distributions gentoo, sorcerer... et lfs
11. Conclusion
12. Références

1. Introduction

GNU/Linux est un système d'application libre et c'est peut-être pour cela que vous l'avez choisi. Mais sur un système d'exploitation GNU/Linux, de nombreuses applications, de nombreux programmes tournent, et la plupart sont libres aussi. Citons entre autres mozilla, galeon ou konqueror pour aller sur internet, votre bureau gnome ou kde, openoffice.org ou koffice pour la bureautique, et j'en passe.

Un programe est libre s'il respecte quelques règles de bases, comme la possibilité de lire et/ou modifier librement le code source du programme. Pour les autres libertés garanties par un logiciel libre, voyez le numéro précédent de Linux Pratique. Lire et/ou modifier le code source du programme implique que vous puissiez disposer de ce code source, et donc que vous soyez à même de recompiler vos propres binaires d'une application, plutôt que d'utiliser ceux recompilés sur une autre machine que la votre.

Vous pouvez recompiler vos programmes, et pourtant certaines distributions comme Mandrake ou Debian tentent de rivaliser devant le nombre de paquets mis à votre disposition, vous évitant cette peine. Alors, faut-il recompiler ses applications?

2. Un peu de vocabulaire et de théorie

Avant de rentrer dans le vif du sujet, je voudrais vous rappeler ce qu'on appelle un binaire. C'est un fichier, qui contient le programme d'une certaine façon, et qu'on exécute afin de lancer le programme. Il s'appelle binaire parce que la plupart du temps le fichier dit binaire contient des données binaires, illisibles par l'homme.

Pour générer un fichier binaire, on prend un code source et on le compile. Cela signifie que l'on va exécuter un programme, typiquement le compilateur C ou C++, en lui fournissant le code source, fichier qu'un programmeur a écrit, et qui va générer ce fichier binaire exécutable.

Lorsque vous installez GNU/Linux sur votre ordinateur, vous ne voyez rien de cela. En fait, tout ce travail a déjà été fait, et en simplifiant beaucoup, les programmes présents sur le CD d'installation sont déjà compilés, prêts à être recopiés sur votre disque dur, et prêts à l'emploi. Et du coup, il est probable que vous ne vous soyez même pas posé la question de refaire le travail de recompilation.

3. Pourquoi les recompiler?

L'intérêt qu'il y a à recompiler ses applications est le suivant: vous recompilez votre application comme vous le voulez, sur votre machine, pour votre machine. Vous n'utilisez pas un programme binaire qui a été recompilé pour une machine générique, en tenant compte d'une installation générique de GNU/Linux, mais un binaire spécialement conçu en fonction de votre système. Par exemple, l'application MPlayer, qui vous sert à lire les DVD et autres vidéos, est compilée généralement pour fonctionner sur une machine à base d'un processeur Intel. Pourtant, si vous recompilez MPlayer, vous pourrez activer certaines optimisations parce que vous avez un processeur Intel Pentium MMX, ou un AMD Athlon, avec d'autres spécificités encore. Ainsi, la lecture des vidéos prendra moins de puissance du processeur et utilisera au mieux votre matériel.

Un autre intérêt et tout aussi courant, est de pouvoir disposer de la dernière version de tel ou tel logiciel, parce que la dernière version apporte telle ou telle fonctionalité géniale qui n'est pas dans la version installée sur votre ordinateur. Tout cela parce que votre distribution n'est pas très réactive et que le paquet n'existe pas et n'existera pas avant un certain temps. Dans ce cas, pour disposer de la dernière version de votre logiciel, vous n'avez pas d'autre choix que de le recompiler.

Autre raison de recompiler ses applications encore, si vous voulez installer l'application dans un répertoire différent que celui prévu par votre distribution, parce que vous n'avez pas le mot de passe administrateur pour installer le paquet dans l'arborescence normale. Alors vous n'avez là non plus, pas d'autre choix que de recompiler l'application et de l'installer dans un répertoire où vous avez la permission d'écrire.

4. Contraintes et ennuis en vue

La première contrainte, lorsque vous recompilez une application, est d'avoir les logiciels de compilation disponibles. Si vous n'avez pas le compilateur installé, installez-le. Si vous ne pouvez pas, oubliez, et passez à autre chose, comme la culture des carottes ou l'étude des galaxies lointaines.

Contrainte suivante: vous devez avoir du temps devant vous. En effet, si les distributions GNU/Linux comme Mandrake ou Debian et les autres ont tant de succès, c'est parce qu'en vous fournissant les binaires déjà compilés, elles vous évitent un temps de recompilation assez énorme. Prévoyez plusieurs heures pour recompiler XFree86, Mozilla ou OpenOffice.org par exemple. Par contre, sachez que l'ordinateur a besoin de vous au début pour lancer la compilation, et à la fin pour l'installation. Entre temps, vous pouvez vous consacrer à d'autres activités comme la culture des carottes ou l'étude des galaxies lointaines.

La troisième contrainte est une containte un peu moins évidente au premier abord, mais plus désagréable et plus embétante. C'est celle de la gestion des dépendances. En effet, un programme dépend d'un autre, qui dépend d'encore un autre, et ainsi de suite. Et la version de chacune de ces dépendances a son importance. Ainsi, un logiciel va dépendre de la version 2 de libxml, qui elle dépend d'une version récente de zlib, etc. Vous devez donc non seulement recompiler l'application que vous avez décidé de recompiler, mais aussi ses dépendances. Vous pouvez néanmoins choisir de n'en recompiler qu'une partie et d'installer les paquets fournis par votre distribution pour le reste s'ils conviennent. Pour les dépendances que vous allez recompiler, cela vous fait encore du temps en plus. Et là, les dépendances sont souvent de petits morceaux, qui se compilent vite, qui s'installent vite, et qui ne vous laissent que une ou deux minute de répit, assez de quoi vous faire perdre votre temps, mais pas assez pour la culture des carottes ou l'étude des galaxies lointaines.

5. Comment cela évolue ensuite?

Une application dépend de bibliothèques, que l'on appelle souvent librairies à tort, à cause du faux ami anglais library. Une bibliothèque est un morceau de logiciel, fournissant à votre application ainsi qu'à d'autres, un ensemble de fonctionnalités communes. L'avantage d'un tel système est qu'il n'y a pas besoin de réinventer la roue à chaque fois. Cela assure de plus une certaine homogénéité fonctionnelle, graphique dans le cas d'une bibliothèque graphique comme gtk+ (gnome) ou qt (kde), et de plus, si un bug apparaît, on le corrige une seule fois et il est corrigé pour toutes les applications qui utilisent cette bibliothèque. A condition de garder cette bibliothèque à jour bien sur.

Si vous avez décidé de recompiler une application et l'une ou l'autre bibliothèques dont elle dépend, vous devez ensuite maintenir à jour non seulement l'application, mais aussi ces bibliothèques. Si une bibliothèque doit être recompilée pour corriger un bug, vous devez aussi recompiler toutes vos applications qui en dépendent, même si le seul changement est la bibliothèque.

Tout cela apparaît simple dans le principe. En pratique, cela est différent, et ressemble vite à un cauchemar. En effet, si vous recompilez vos applications et vos bibliothèques, vous n'avez pas les paquets correspondants. Du coup, les schémas de dépendances sont noté nulle part. Vous n'avez pas vraiment de moyen efficace de savoir si, en changeant un composant, quelle est la liste des programmes et bibliothèques qui en dépendaient. En changeant une bibliothèque, vous risquez donc d'avoir une application qui ne fonctionne plus, ou qui plante alors qu'elle ne plantait pas avant, ou qui fonctionne moins bien... Vous pouvez aussi tenter de faire cohabiter deux versions différentes d'une même bibliothèque, ce qui est tout à fait possible, en théorie et souvent en pratique aussi. Mais ensuite, quand vous recompilez une application, ce n'est plus très simple de savoir quelle version de la bibliothèque il doit utiliser. Et si vous faites le ménage en supprimant les vieilles versions des bibliothèques, peut-être qu'un programme s'en servait encore et ne marchera plus?

A cause d'une part du temps que vous allez passer à recompiler vos applications, et d'autre part des ennuis que vous allez vous attirer à cause des dépendances, problèmes dus à la cohabitation de bibliothèques de versions différentes, et autres joyeusetés plus exotiques encore, je vous déconseille de recompiler une application si vous n'avez pas une raison sérieuse de le faire.

6. Peut-on vivre sans recompiler ses applications?

Il y a quelques années, ne pas recompiler ses applications signifiait avoir un système un peu dépassé, comme si vous aviez windows 3.1 alors que windows 95 était sorti. Aujourd'hui, si l'on ne recompile pas ses applications, on se retrouve dans la plupart des cas avec un système qui fonctionne très bien, à peine dépassé, avec une ou deux fonctionnalités manquantes seulement. Cela est à comparer entre un windows Millénium et un windows 98 par exemple. Pour le plus gros de votre système, il est inutile de recompiler quoi que ce soit, même si vos amis, mordus de Linux, vous disent le contraire et se justifient en affirmant que xchat-1.9 utilise maintenant gnome-2 alors que xchat-1.8 en est resté à gnome-1.4.

D'ailleurs, avez-vous remarque que sur GNU/Linux, les numéros de versions ont une importance beaucoup plus grande que les numéros de versions sur Windows? Sur Windows, vous allez utiliser la version 7 de l'antivirus, et internet explorer 6 sur Windows 2000, alors que sur GNU/Linux, vous avez un noyau 2.4.18 et une glibc-2.2.5, votre bureau est un gnome-2.0 et vous utilisez galeon-1.2 mais vous songez à passer au noyau 2.4.20 et à mettre mozilla-1.2.1 et galeon-1.3. Sur GNU/Linux, les numéros de versions impressionnent un peu plus parce que les versions se suivent et se succèdent, à un rythme bien supérieur à celui de Windows. En fait, sur GNU/Linux, vous avez souvent une version stable d'un logiciel, et une version qui vient de sortir mais en développement, donc instable. Parler de numéros de versions, ce qui a peu de signification sur un système Windows, prend tout son intérêt sur un système GNU/Linux parce qu'on parle implicitement de la stabilité d'un logiciel ou des fonctionnalités récemment ajoutées à ce logiciel.

Par ailleurs, la stabilité du système faisant partie en quelques sortes de sa sécurité d'utilisation, notez que si vous recompilez vos applications, vous risquez de perdre en stabilité. En effet, les distributions vous fournissent un système de la meilleure stabilité qu'ils peuvent. D'une part ce sont des spécialistes, et si jamais vous pensez que vous pouvez rivaliser avec eux, tentez plutôt de vous faire embaucher. D'autre part, avoir un morceau que vous avez recompilé vous-même n'est pas prévu par les gens qui ont créé les paquets de la distribution. Cela peut amener à des situations exotiques où un paquet s'installe alors qu'il ne devrait pas faute de prérequis, mais fonctionne mal ou pas du tout parce que le prérequis est manquant ou dans une version différente de celle attendue.

De nos jours, toutes les grandes distributions, Mandrake, Debian, Redhat et autres, fournissent de plus des paquets de mise à jour en cas de découverte d'un bug majeur. Ces mises à jour sont appelées soit errata, soit mises à jour (updates). Elles sont disponibles généralement dès que le correctif a été publié, donc vous avez peu de chance de les prendre de vitesse. En cas de découverte d'un bug, même dans ce cas, il reste préférable d'utiliser le paquet de votre distribution plutôt que de le recompiler vous-même. Au pire, si le correctif se fait attendre, prenez un peu sur votre temps pour revenir sur la culture des carottes ou l'étude des galaxies lointaines. Le correctif arrivera quand même ou bout d'un jour ou deux, et le paquet de mise à jour dans les heures qui suivent.

Toujours au sujet de la sécurité, vous pourriez objecter que si vous avez les sources d'un logiciel et que vous le recompilez à partir de ces sources, vous êtes sur qu'il n'y a pas de virus, ou plutôt cheval de Troie, dedans. Et que si vous installez le paquet de votre distribution, il y a plus de chance qu'il y ait un cheval de Troie dedans. Si vous êtes paranoïaque à ce point, je voudrais vous faire réfléchir sur ceci: vous disposez des sources du logiciel, mais allez-vous les lire en entier et les comprendre du début à la fin pour vérifier qu'il n'y a effectivement pas de cheval de Troie? Ceci est pourtant la seule méthode pour vous en assurer. Si on part dans un principe de paranoïa, rien n'empèche à un programmeur d'insérer un tel bout de code à l'intérieur de son propre programme. Même si vous vous assurez que le code source dont vous disposez est identique à l'original, il y aura un bout de code non désiré à l'intérieur du programme. Et si vous soupçonnez un programme, ou deux, pourquoi ne pas soupçonner tous les programmes installés sur votre ordinateur? La relecture des sources en entier est impossible pour une seule personne, et il vous faut faire confiance au programmeurs. Ensuite, j'estime que vous pouvez faire une confiance totale à votre distribution en ce sens que sa réputation est en jeu si jamais on découvre qu'elle a rajouté un bout de code inattendu au programme original et que cela se découvre. Donc soyez rassuré pour la sécurité de votre système: ce n'est pas en recompilant vos applications que vous allez gagner en sécurité.

7. Comment recompiler ses applications

Si vous avez décidé malgré tout de recompiler une application ou une bibliothèque, voici quelques méthodes pour faire cela simplement et proprement. Cela ne marche pas à tous les coups, mais souvent quand même.

7.1. La compilation

  • Première chose à faire: cherchez un fichier README ou INSTALL ou équivalent. Il vous fournira les instructions pour recompiler et installer votre application, avec des détails spécifiques.

  • S'il y a un script configure, exécutez ./configure --help et lisez les options que vous pouvez ajouter, en fonction de ce que vous voulez faire. Puis exécutez ./configure --prefix=/usr/local <d'autres options ici>. Mettez autre chose que /usr/local si vous préférez compiler votre application pour l'installer ailleurs.

  • S'il n'y a pas de script configure, et qu'on vous propose de faire tout de suite make, cherchez un fichier Makefile, et lisez-le à la recherche d'un répertoire d'installation, souvent contenu dans la variable prefix. Modifiez le fichier Makefile en fonction de vos besoins.

  • Dans la plupart des cas, lancez ensuite make. Ceci est l'étape longue, et à moins de vouloir aller boire un café, ce qu'on conseille souvent lors de cette étape, je vous suggère de passer un moment à la culture des carottes ou à l'étude des galaxies lointaines. Si tout se passe sans problème, ce qui arrive souvent, mais pas 100% du temps, votre application est compilée. Il suffit de l'installer. S'il y a le moindre problème, vous allez devoir fouiller partout à la recherche du moindre renseignement pouvant vous aider à améliorer la situation. La plupart du temps, le problème est un prérequis manquant, tel une bibliothèque que vous n'avez pas installée, ou dont vous n'avez pas installé les fichiers de développement (paquets souvent nommés *-devel-* ou *-dev-*). Installez dans ce cas ce qu'il manque, et repartez à zéro en supprimant le répertoire des sources et en décompressant à nouveau les sources.

7.2. L'installation

Dans la plupart des cas, un simple make install suffit à installer l'application. Cependant, je voudrais attirer votre attention sur un logiciel sympathique malgré ses nombreux défauts, GNU Stow. En effet, s'il est assez conseillé d'installer vos logiciels dans /usr/local, ce qui les mélange entre eux, il est aussi de bon goût de les installer séparément, chacun dans son répertoire. Mais ces deux méthodes sont incompatibles. Pour les rendre compatibles, il faudrait installer vos applications dans des répertoires différents, puis créer des liens symboliques des fichiers réellement installés de votre application qui pointent sur les fichiers qui auraient dus être installés si vous aviez installé votre application dans /usr/local. Par exemple, si vous voulez installer l'éditeur nedit, il se trouve que cet éditeur n'est composé que du seul fichier binaire nedit (les autres fichiers ne sont pas nécessaires au bon fonctionnement de nedit). Installez le fichier binaire nedit dans le répertoire /opt/nedit/nedit-5.2/bin. Et créez un lien pointant vers /usr/local/bin/nedit: ln -s /opt/nedit/5.2/bin/nedit /usr/local/bin/nedit. Dans le cas de nedit, cela est simple. Dans d'autres cas, quand il y a trop de fichiers, GNU Stow vient à la rescousse. Voici simplement comment vous en servir, par exemple pour l'application machinchose version 1.2.3:

LINK /usr/local/share/locale/fr to ../../../../opt/machinchose/machinchose-1.2.3/share/locale/fr
LINK /usr/local/share/locale/fr/LC_MESSAGES to ../../../../../opt/machinchose/machinchose-1.2.3/share/locale/fr/LC_MESSAGES
  • Au lieu de faire make install, faites make install prefix=/opt/machinchose/machinchose-1.2.3. Notez que vous devriez quand même avoir fait ./configure --prefix=/usr/local dans ce cas, pour que le logiciel se croie malgré tout installé dans /usr/local.

  • Allez dans le répertoire /opt/machinchose. Vous exécutez stow -t /usr/local -n -v machinchose-1.2.3. Cela vous affichera ce que stow va effectuer. Avec l'option -n, rien n'est fait.

  • Un défaut de GNU Stow est de ne pas créer les répertoires nécessaires, mais de créer des liens entre répertoires. Avant de passer à l'action, je vous conseille donc de devenir root et de créer les répertoires qu'il faut, en fonction de ce que la commande précédente stow vous aura affiché. Refaites cette commande, toujours avec l'option -n, jusqu'à ce qu'elle vous indique qu'elle ne fera que des liens entre les fichiers, ou alors, que s'il y a des liens entre des répertoires, que ces répertoires soient spécifiques à l'application. Voici un extrait de la commande précédente:

  • Ceci est à éviter car d'autres applications sont susceptibles d'utiliser le répertoire /usr/local/share/locale/fr. Veuillez créer un répertoire /usr/local/share/locale/fr et recommencer. Cela donne:

  • Cela est encore à éviter car le répertoire fr, commme le répertoire LC_MESSAGES, ne sont pas spécifiques à notre application. Vous vous arrêtez de créer des répertoires lorsque la commande stow indique ne faire plus que des liens entre fichiers ou entre des répertoires spécifiques à votre application.

  • Lorsque l'arborescence est convenable, et en tant que root, vous exécutez stow -t /usr/local -v machinchose-1.2.3, sans le -n, afin que stow fasse effectivement les liens.

L'installation d'un logiciel tel que machinchose-1.2.3 dans l'arborescence /opt/machinchose/machinchose-1.2.3 a l'intérêt que toutes les versions de machinchose seront installées dans /opt/machinchose, et chacune dans un répertoire différent. Et si vous voulez supprimer toutes les versions de machinchose, il suffit de supprimer /opt/machinchose.

7.3. La désinstallation

Si vous voulez supprimer un logiciel que vous avez installé après l'avoir recompilé et installé vous-même, cela est risqué. En effet, vous pouvez briser des dépendances comme je l'ai écrit plus haut. Vous pouvez aussi, si vous avez installé votre logiciel dans /usr/local, supprimer un fichier de trop en vous trompant. Inversement, vous pouvez oublier de supprimer des fichiers, ce qui vous fera perdre de la place sur le disque. Installer une nouvelle version par dessus l'ancienne version du logiciel ne fera qu'écraser qu'une partie des fichiers de l'ancienne version. Certains fichiers obsolètes resteront encore là alors qu'on en n'a plus besoin. Il existe une méthode très peu utilisée et contraignante, mais souvent efficace: vous devez conserver le répertoire des sources tel qu'il était lors de la compilation du logiciel - cela vous oblige à réserver de la place disque pour cela alors que vous en aviez peut-être besoin pour autre chose? - et là où vous aviez lancé make install, essayez make uninstall. Au vu des contraintes de cettes méthodes, elle est quasiment jamais employée.

Si vous avez suivi ma méthode avec GNU Stow ci-dessus, on peut s'en sortir plus facilement et plus proprement. Allez dans le répertoire /opt/machinchose, et exécutez stow -t /usr/local -d -n -v machinchose-1.2.3. Cela devrait vous afficher ce qui va se passer lorsque vous aurez supprimé l'option -n. Si cela vous convient, lancez la même commande en tant que root, et sans l'option -n pour supprimer les liens symboliques, nettoyant ainsi proprement le répertoire /usr/local. Ensuite, il ne vous reste qu'à supprimer le répertoire machinchose-1.2.3 avec le très efficace rm -rf machinchose-1.2.3.

8. Veuillez utiliser les paquets de votre distribution

Maintenant que nous avons vu que recompiler ses applications n'était pas souhaitable sauf intérêt spécifique, maintenant que nous avons vu comment le faire quand même, je vais vous faire réfléchir un peu sur l'intérêt des paquets de votre distribution.

Toutes les distributions utilisent des paquets (packages, en anglais, souvent aussi traduit paquetage), et ce n'est pas pour rien. En effet, les paquets contiennent les fichiers prêts à être installés sur votre disque dur, en les recopiant, ce qui est très rapide. Les gens qui créent ces paquets vous évitent donc le temps et les contraintes désagréables de la recompilation des applications. Les paquets contiennent aussi des informations relatives aux dépendances. Ainsi, en installant un nouveau paquet, vous savez tout de suite quels paquets sont nécessaires pour que les dépendances soient installées aussi. Et il y a ni conflits ni problèmes de dépendances manquantes en utilisant ce système. Enfin, les paquets contiennent quelques informations, entre autres un descriptif de ce que contient le paquet, souvent l'endroit où l'on peut récupérer le code source, ou le site web officiel de l'application...

Pour utiliser les paquets de votre distribution, certaines commandes sont mises à votre disposition pour vous faciliter la tâche. Si vous avez installé une Mandrake, utilisez rpmdrake si vous êtes un adepte de la souris et des clics, ou urpmi <le nom de l'application> si vous préférez la ligne de commande. Sur une Debian, c'est uniquement en ligne de commande et c'est apt-get install <le nom du paquet de l'application>.

GNU Stow dont je vous ai parlé ci-dessus n'est pas un système de gestion de paquets, contrairement aux apparences. GNU Stow, qui marche quelle que soit la distribution sur laquelle vous vous en servez, se contente uniquement de créer des liens symboliques et de les enlever. En aucun cas, il ne gère les dépendances. En aucun cas, il ne peut se substituer à un système de gestion de paquets comme rpm sur Mandrake et Redhat par exemple, ou deb sur Debian. En aucun cas donc, vous ne l'utiliserez comme tel, en complément ou en remplacement du système de gestion des paquets de votre distribution.

Il y a quelques années, les paquets manquaient pour la plupart des distributions et il n'était pas rare que l'on trouve un paquet pour une distribution qui n'était pas la notre et qu'on l'installe quand même, par exemple installer un paquet Suse sur une Redhat. Cela ne fonctionne pas dans tous les cas et n'a jamais fonctionné dans tous les cas. Cela est en plus à éviter parce que pour un même logiciel, les paquets de certaines distributions n'ont pas les mêmes prérequis que pour d'autres distributions, et ne fournissent pas forcément les mêmes dépendances. Actuellement, les distributions majeures, Mandrake, Debian, Redhat, Slackware et les autres fournissent des paquets pour un grand nombre de logiciels et il est vraiment préférable de n'installer que des paquets propre à sa distribution. N'hésitez donc pas à installer des paquets contribs de Mandrake sur votre Mandrake, ou des paquets FreshRpms sur votre Redhat...

9. Votre distribution bleeding-edge

Bleeding-edge signifie dernier cri, c'est-à-dire que vous pouvez avoir sur votre système les toutes dernières versions des logiciels que vous utilisez. Ceci était un argument en faveur de la recompilation d'une application. Nous allons voir que recompiler une application n'est pas le seul moyen d'avoir un système dernier cri, et que l'on peut donc là encore se passer de recompiler ses applications.

Si vous avez déjà entendu parler de Cooker sur Mandrake, de Debian Sid, de Rawhide sur Redhat ou de Slackware-Current (chaque distribution a son nom), sachez que là, on parle d'une distribution à la fois bleeding-edge et à la fois instable. Avoir la toute dernière version d'un logiciel implique donc d'avoir un logiciel instable. Et de la même manière, avoir une distribution à la pointe signifie aussi avoir une distribution instable.

En quoi consiste cette instabilité? Pour la distribution, si vous installez la branche instable d'une distribution, vous n'êtes pas à l'abri d'une fausse manipulation d'un packager, qui pourrait ainsi ruiner votre système. De plus, cette distribution instable est mise à jour tous les jours en fonction des nouveautés du moment, ce qui augmente le risque par rapport à la branche stable, mise à jour (nouvelle version) tous les 3 mois ou tous les 6 mois. Inversement, pour une distribution stable, les risques sont très réduits puisque beaucoup de monde a testé la version stable, qui n'est sortie qu'après de nombreux tests. Installer une distribution instable vous fait donc prendre un risque dont vous devez tenir compte. Vous devez entre autres n'avoir aucune donnée importante, ou alors faire des sauvegardes régulièrement si vous choisissez de l'installer. Vous devez aussi, en cas de problème, prendre le risque de devoir tout réinstaller depuis zéro, ce qui vous rendrait temporairement votre GNU/Linux indisponible. La loi de Murphy précise de plus que cela arrive toujours au mauvais moment! Pourtant, si ce risque existe, sachez que par expérience, personnelle avec Mandrake Cooker, et par ouï-dire pour Debian Sid comme pour Mandrake Cooker (aucun echo pour ma part pour les autres distributions), ce risque est assez faible (je n'ai été qu'à deux doigts de la catastrophe qu'une seule fois en un an, et même cette fois-là, la catastrophe a été évitée, de justesse). Une distribution dite instable est utilisable, quoi qu'on en dise. Cependant, vous aurez quand même été averti si vous venez à en utiliser une.

Cette instabilité existe aussi pour chaque logiciel. En effet, la dernière version d'un logiciel n'est pas à l'abri d'un bug, et comme la plupart des logiciels n'ont été testés que par un maximum d'une dizaine de personnes pendant quelques minutes. Vous pourriez donc, en utilisant un logiciel dans une version qui vient de sortir, découvrir vite fait un bug très désagréable. Et lorsqu'il s'agit d'une bibliothèque utilisée par de nombreux programmes, c'est l'ensemble du système qui en devient difficilement utilisable. Ce fut par exemple le cas pour Mandrake Cooker alors qu'on utilisait déjà gnome-2.0 mais qu'il n'était pas encore officiellement sorti: la stabilité de gnome était alors déplorable. En utilisant une distribution dite stable, vous avez des logiciels qui ont déjà été testés pendant un certain temps, et les bugs dont on s'aperçoit tout de suite ont disparu. Le gnome-2.0 disponible dans la Mandrake-9.0 est d'ailleurs plutôt stable. Si vous utilisez la branche instable d'une distribution, avec des logiciels dans des versions qui viennent de sortir, même si la distribution est relativement stable, elle est néanmoins instable par les logiciels qui la composent. Vous prenez donc un risque aussi avec les logiciels qui viennent de sortir.

Stabilité ou dernier cri, les deux sont incompatibles, et c'est à vous de choisir. Si vous hésitez, préférez rester sur une distribution stable, en vous contentant de mettre à jour les paquets quand une mise à jour de sécurité a lieu.

10. Les distributions gentoo, sorcerer... et lfs

Il existe des distributions comme gentoo ou sorcerer dont le principe consiste à non pas installer des paquets dont les fichiers sont déjà tout prêts à l'emploi, mais à installer les fichiers sources et le nécessaire pour recompiler facilement tout ce qui va être installé. Si vous tenez à recompiler les applications sur votre GNU/Linux, sachez que ces distributions ont l'avantage de vous oter toutes les contraintes de la recompilation, en particulier la contrainte de la gestion des dépendances. Ces distributions sont à base de paquets comme les autres, paquets qui contiennent des informations sur les dépendances. Elles vous otent toutes les contraintes, sauf une: la contrainte de temps. Pour installer un tel système, vous allez avoir besoin d'énormément de temps car vous allez devoir tout recompiler, tout le système dans son intégralité. Prévoyez des dizaines d'heures de recompilation, si ce n'est plus, suivant la puissance de votre machine. Cela vous laissera du coup pas mal de temps pour la culture des carottes ou l'étude des galaxies lointaines.

LFS, Linux From Scratch, n'est pas une distribution, mais un guide d'installation de GNU/Linux, en partant de rien, ou plutôt en partant des sources des logiciels. Installer un LFS est pire que l'installation d'une gentoo ou d'une sorcerer parce que vous devez tout faire vous même. Non seulement il vous faudra prévoir du temps pour la compilation de vos applications, mais il vous faudra aussi gérer le problème des dépendances. LFS ne s'installe pas vraiment pour installer GNU/Linux, mais plutôt pour apprendre ce qui compose un système GNU/Linux, ses fondements, son fonctionnement... Si vous débutez avec GNU/Linux, préférez apprendre d'autres choses avant de tenter l'aventure d'un LFS: c'est vraiment une grande aventure. Elle vaut le coup: si vous vous sentez prêt, tentez-la.

Ces distributions, qui vous font tout recompiler, ne sont pas vraiment intéressantes si vous démarrez avec GNU/Linux. Si vous voulez découvrir autre chose que la distribution avec laquelle vous avez découvert GNU/Linux, essayez une autre distribution parmi Mandrake, Debian, Redhat, Slackware. Vous recompilerez vos applications un autre jour.

11. Conclusion

Cet article vous aura permis de voir que l'on peut recompiler ses applications, mais qu'il vaut mieux s'en passer dans la mesure du possible. Il est préférable d'installer les paquets déjà prêts à l'emploi et optimisés en fonction de ce qui est déjà installé sur votre système. Comme j'ai beaucoup parlé de paquets et de distributions, vous aurez pu voir quelques caractéristiques intéressantes de GNU/Linux, communes aux distributions, et que vous pouvez retrouver sur la votre. Il ne vous reste maintenant plus qu'à explorer les nombreuses applications disponibles sur votre distribution, et je vous invite à commencer par en découvrir quelques unes qui m'ont beaucoup plu, comme tuxracer, petit jeu bien sympathique, ou xmms pour lire vos fichiers audio, gnucash pour gérer vos comptes bancaires, ou gqview pour voir vos images.

12. Références

création est mise à disposition sous un contrat Creative Commons