Bref: Ce guide détaillé explique comment installer un programme à partir du code source sous Linux et comment supprimer le logiciel installé du code source.

L’une des plus grandes forces de votre distribution Linux est son gestionnaire de paquets et le référentiel logiciel associé. Avec eux, vous disposez de tous les outils et ressources nécessaires pour télécharger et installer de nouveaux logiciels sur votre ordinateur de manière complètement automatisée.

Mais malgré tous leurs efforts, les responsables de paquets ne peuvent pas gérer tous les cas d’utilisation. Ils ne peuvent pas non plus emballer tous les logiciels disponibles. Il y a donc encore des situations où vous devrez compiler et installer vous-même de nouveaux logiciels. Quant à moi, la raison la plus courante, de loin, je dois compiler certains logiciels est lorsque j’ai besoin d’exécuter une version très spécifique, ou de modifier le code source en utilisant des options de compilation fantaisistes.

Si vos besoins appartiennent à cette dernière catégorie, il y a de fortes chances que vous sachiez déjà quoi faire. Mais, pour la grande majorité des utilisateurs de Linux, compiler et installer des logiciels à partir du code source pour la première fois pourrait ressembler à une cérémonie d’initiation: quelque peu effrayante; mais avec la promesse d’entrer dans un nouveau monde de possibilités et une place de prestige dans une communauté privilégiée.

A. Installer un logiciel à partir du code source sous Linux

Et c’est exactement ce que nous allons faire ici. Pour les besoins de cet article, disons que je dois installer NodeJS 8.1.1 sur mon système. Cette version exactement. Une version qui n’est pas disponible dans le dépôt Debian :

sh$ apt-cache madison nodejs | grep amd64 nodejs | 6.11.1~dfsg-1 | http://deb.debian.org/debian experimental/main amd64 Packages nodejs | 4.8.2~dfsg-1 | http://ftp.fr.debian.org/debian stretch/main amd64 Packages nodejs | 4.8.2~dfsg-1~bpo8+1 | http://ftp.fr.debian.org/debian jessie-backports/main amd64 Packages nodejs | 0.10.29~dfsg-2 | http://ftp.fr.debian.org/debian jessie/main amd64 Packages nodejs | 0.10.29~dfsg-1~bpo70+1 | http://ftp.fr.debian.org/debian wheezy-backports/main amd64 Packages

Maintenant, installer NodeJS sur Ubuntu ou Debian est assez simple si vous le faites avec le gestionnaire de paquets. Mais faisons-le via le code source.

Étape 1: Obtenir le code source de GitHub

Comme de nombreux projets open-source, les sources de NodeJS peuvent être trouvées sur GitHub: https://github.com/nodejs/node

Alors, allons-y directement.

Si vous n’êtes pas familier avec GitHub, git ou tout autre système de contrôle de version digne de mention, le référentiel contient la source actuelle du logiciel, ainsi qu’un historique de toutes les modifications apportées au fil des ans à ce logiciel. Finalement jusqu’à la toute première ligne écrite pour ce projet. Pour les développeurs, garder cet historique présente de nombreux avantages. Pour nous aujourd’hui, le principal est que nous pourrons obtenir les sources du projet telles qu’elles étaient à un moment donné. Plus précisément, je pourrai obtenir les sources telles qu’elles étaient lors de la sortie de la version 8.1.1 que je veux. Même s’il y a eu de nombreuses modifications depuis lors.

Sur GitHub, vous pouvez utiliser le bouton « branche” pour naviguer entre les différentes versions du logiciel. « Branch » et « tags » sont des concepts quelque peu liés dans Git. Fondamentalement, les développeurs créent des « branches » et des ”tags » pour suivre les événements importants de l’historique du projet, comme lorsqu’ils commencent à travailler sur une nouvelle fonctionnalité ou lorsqu’ils publient une version. Je n’entrerai pas dans les détails ici, tout ce que vous devez savoir, c’est que je cherche la version étiquetée « v8.1.1”

Après avoir choisi sur la « v8.1.1 « tag, la page est actualisée, le changement le plus évident étant que la balise apparaît désormais dans l’URL. De plus, vous remarquerez que la date de changement de fichier est également différente. L’arborescence source que vous voyez maintenant est celle qui existait au moment de la création de la balise v8.1.1. Dans un certain sens, vous pouvez penser à un outil de contrôle de version comme git comme une machine à voyager dans le temps, vous permettant de faire des allers-retours dans l’historique d’un projet.

À ce stade, nous pouvons télécharger les sources de NodeJS 8.1.1. Vous ne pouvez pas manquer le gros bouton bleu suggérant de télécharger l’archive ZIP du projet. Quant à moi, je vais télécharger et extraire le ZIP de la ligne de commande pour l’explication. Mais si vous préférez utiliser un outil graphique, n’hésitez pas à le faire à la place:

wget https://github.com/nodejs/node/archive/v8.1.1.zipunzip v8.1.1.zipcd node-8.1.1/

Le téléchargement de l’archive ZIP fonctionne très bien. Mais si vous voulez le faire « comme un pro », je vous suggère d’utiliser directement l’outil git pour télécharger les sources. Ce n’est pas compliqué du tout — et ce sera un bon premier contact avec un outil que vous rencontrerez souvent:

# first ensure git is installed on your systemsh$ sudo apt-get install git# Make a shallow clone the NodeJS repository at v8.1.1sh$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/nodesh$ cd node/

Au fait, si vous avez un problème, considérez simplement la première partie de cet article comme une introduction générale. Plus tard, j’ai des explications plus détaillées sur les distributions basées sur Debian et RedHat afin de vous aider à résoudre les problèmes courants.

De toute façon, chaque fois que vous avez téléchargé la source en utilisant git ou en tant qu’archive ZIP, vous devriez maintenant avoir exactement les mêmes fichiers source dans le répertoire courant:

sh$ lsandroid-configure BUILDING.md common.gypi doc Makefile srcAUTHORS CHANGELOG.md configure GOVERNANCE.md node.gyp testbenchmark CODE_OF_CONDUCT.md CONTRIBUTING.md lib node.gypi toolsBSDmakefile COLLABORATOR_GUIDE.md deps LICENSE README.md vcbuild.bat

Étape 2: Comprendre le système de construction du programme

Nous parlons généralement de « compilation des sources”, mais la compilation n’est qu’une des phases nécessaire pour produire un logiciel fonctionnel à partir de sa source. Un système de construction est un ensemble d’outils et de pratiques utilisés pour automatiser et articuler ces différentes tâches afin de construire entièrement le logiciel simplement en émettant quelques commandes.

Si le concept est simple, la réalité est un peu plus compliquée. Parce que différents projets ou langages de programmation peuvent avoir des exigences différentes. Ou à cause des goûts du programmeur. Ou les plates-formes prises en charge. Ou pour des raisons historiques. Ou… ou.. il existe une liste presque infinie de raisons de choisir ou de créer un autre système de construction. Tout cela pour dire qu’il existe de nombreuses solutions différentes utilisées.

NodeJS utilise un système de construction de style GNU, c’est un choix populaire dans la communauté open source et encore une fois, un bon moyen de commencer votre voyage.

Écrire et régler un système de construction est une tâche assez complexe, mais pour « l’utilisateur final », les systèmes de construction de style GNU facilitent la tâche en utilisant deux outils : configure et make.

Le fichier configure est un script spécifique au projet qui vérifiera la configuration du système de destination et la fonctionnalité disponible afin de s’assurer que le projet peut être construit, en traitant éventuellement les spécificités de la plate-forme actuelle.

Une partie importante d’un travail configure typique consiste à construire le Makefile. C’est le fichier contenant les instructions nécessaires pour construire efficacement le projet.

L’outil make, quant à lui, est un outil POSIX disponible sur n’importe quel système de type Unix. Il lira le Makefile spécifique au projet et effectuera les opérations requises pour créer et installer votre programme.

Mais, comme toujours dans le monde Linux, vous avez toujours une certaine clémence dans la personnalisation de la version à vos besoins spécifiques.

./configure --help

La commande configure -help vous montrera toutes les options de configuration disponibles. Encore une fois, c’est très spécifique au projet. Et pour être honnête, il est parfois nécessaire de creuser dans le projet avant de bien comprendre le sens de chaque option de configuration.

Mais il existe au moins une option standard des outils automatiques GNU que vous devez connaître : l’option --prefix. Cela a à voir avec la hiérarchie du système de fichiers et l’endroit où votre logiciel sera installé.

Étape 3: Le FHS

La hiérarchie du système de fichiers Linux sur une distribution typique est généralement conforme à la norme de hiérarchie du système de fichiers (FHS)

Cette norme explique le but des différents répertoires de votre système : /usr/tmp/var et ainsi de suite.

Lorsque vous utilisez les outils automatiques GNU — et la plupart des autres systèmes de construction — l’emplacement d’installation par défaut de votre nouveau logiciel sera /usr/local. Quel est un bon choix car selon la FSH « La hiérarchie /usr/local est à utiliser par l’administrateur système lors de l’installation locale du logiciel? Il doit être à l’abri d’être écrasé lorsque le logiciel système est mis à jour. Il peut être utilisé pour des programmes et des données qui peuvent être partagés entre un groupe d’hôtes, mais qui ne se trouvent pas dans /usr.”

La hiérarchie /usr/local réplique en quelque sorte le répertoire racine, et vous y trouverez /usr/local/bin pour les programmes exécutables, /usr/local/lib pour les bibliothèques, /usr/local/share pour les fichiers indépendants de l’architecture et ainsi de suite.

Le seul problème lors de l’utilisation de l’arborescence /usr/local pour l’installation de logiciels personnalisés est que les fichiers de tous vos logiciels y seront mélangés. Surtout, après avoir installé quelques logiciels, il sera difficile de savoir quel fichier exactement de /usr/local/bin et /usr/local/lib appartient à quel logiciel. Cela ne causera cependant aucun problème au système. Après tout, /usr/bin est à peu près le même gâchis. Mais cela deviendra un problème le jour où vous voudrez supprimer un logiciel installé manuellement.

Pour résoudre ce problème, je préfère généralement installer un logiciel personnalisé dans le sous-arbre /opt à la place. Encore une fois, pour citer le FHS:

_”/opt est réservé à l’installation de progiciels d’application complémentaires.

Un paquet à installer dans /opt doit localiser ses fichiers statiques dans une arborescence de répertoires séparée /opt/<package > ou /opt/< fournisseur >, où <package > est un nom qui décrit le package logiciel et < fournisseur > est le nom enregistré LANANA du fournisseur.”_

Nous allons donc créer un sous-répertoire de /opt spécifiquement pour notre installation NodeJS personnalisée. Et si un jour je veux supprimer ce logiciel, je devrai simplement supprimer ce répertoire:

sh$ sudo mkdir /opt/node-v8.1.1sh$ sudo ln -sT node-v8.1.1 /opt/node# What is the purpose of the symbolic link above?# Read the article till the end--then try to answer that# question in the comment section!sh$ ./configure --prefix=/opt/node-v8.1.1sh$ make -j9 && echo ok# -j9 means run up to 9 parallel tasks to build the software.# As a rule of thumb, use -j(N+1) where N is the number of cores# of your system. That will maximize the CPU usage (one task per# CPU thread/core + a provision of one extra task when a process# is blocked by an I/O operation.

Tout sauf « ok” une fois la commande make terminée signifierait qu’il y avait une erreur pendant le processus de construction. Comme nous avons exécuté une construction parallèle en raison de l’option -j, il n’est pas toujours facile de récupérer le message d’erreur étant donné le grand volume de sortie produit par le système de construction.

En cas de problème, redémarrez simplement make, mais sans l’option -j cette fois. Et l’erreur devrait apparaître vers la fin de la sortie :

sh$ make

Enfin, une fois la compilation terminée, vous pouvez installer votre logiciel à son emplacement en exécutant la commande :

sh$ sudo make install

Et le tester:

sh$ /opt/node/bin/node --versionv8.1.1

B. Que se passe-t-il si les choses tournent mal lors de l’installation à partir du code source?

Ce que j’ai expliqué ci-dessus est principalement ce que vous pouvez voir sur la page « instruction de construction” d’un projet bien documenté. Mais étant donné que l’objectif de cet article est de vous permettre de compiler votre premier logiciel à partir de sources, cela pourrait valoir la peine de prendre le temps d’enquêter sur certains problèmes courants. Donc, je vais refaire toute la procédure, mais cette fois à partir d’un nouveau système Debian 9.0 et CentOS 7.0 minimal afin que vous puissiez voir les erreurs que j’ai rencontrées et comment je les ai résolues.

De Debian 9.0 « Stretch »

:~$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node-bash: git: command not found

Ce problème est assez facile à diagnostiquer et à résoudre. Il suffit d’installer le package git:

:~$ sudo apt-get install git

:~$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node && echo okok

:~/node$ sudo mkdir /opt/node-v8.1.1:~/node$ sudo ln -sT node-v8.1.1 /opt/node

Aucun problème ici.

:~/node$ ./configure --prefix=/opt/node-v8.1.1/WARNING: failed to autodetect C++ compiler version (CXX=g++)WARNING: failed to autodetect C compiler version (CC=gcc)Node.js configure error: No acceptable C compiler found! Please make sure you have a C compiler installed on your system and/or consider adjusting the CC environment variable if you installed it in a non-standard prefix.

Évidemment, pour compiler un projet, vous avez besoin d’un compilateur. NodeJS étant écrit en utilisant le langage C++, nous avons besoin d’un compilateur C++. Ici, je vais installer ‘g++’, le compilateur GNU C++ à cet effet:

:~/node$ sudo apt-get install g++:~/node$ ./configure --prefix=/opt/node-v8.1.1/ && echo okok

:~/node$ make -j9 && echo ok-bash: make: command not found

Un autre outil manquant. Mêmes symptômes. Même solution:

:~/node$ sudo apt-get install make:~/node$ make -j9 && echo okok

:~/node$ sudo make install:~/node$ /opt/node/bin/node --versionv8.1.1

Succès!

Veuillez noter: J’ai installé les différents outils un par un pour montrer comment diagnostiquer les problèmes de compilation et vous montrer la solution typique pour résoudre ces problèmes. Mais si vous recherchez plus d’informations sur le sujet ou lisez d’autres tutoriels, vous découvrirez que la plupart des distributions ont des « méta-paquets” agissant comme un parapluie pour installer tout ou partie des outils typiques utilisés pour compiler un logiciel. Sur les systèmes basés sur Debian, vous rencontrerez probablement le package build-essentials à cet effet. Et sur les distributions basées sur Red-Hat, ce sera le groupe « Outils de développement ».

De CentOS 7.0

 ~]$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node-bash: git: command not found

Commande introuvable ? Il suffit de l’installer en utilisant le gestionnaire de paquets yum:

 ~]$ sudo yum install git

 ~]$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node && echo okok

 ~]$ sudo mkdir /opt/node-v8.1.1 ~]$ sudo ln -sT node-v8.1.1 /opt/node

 ~]$ cd node node]$ ./configure --prefix=/opt/node-v8.1.1/WARNING: failed to autodetect C++ compiler version (CXX=g++)WARNING: failed to autodetect C compiler version (CC=gcc)Node.js configure error: No acceptable C compiler found! Please make sure you have a C compiler installed on your system and/or consider adjusting the CC environment variable if you installed it in a non-standard prefix.

Vous le devinez: NodeJS est écrit en utilisant le langage C ++, mais mon système manque du compilateur correspondant. Miam à la rescousse. Comme je ne suis pas un utilisateur régulier de CentOS, j’ai dû rechercher sur Internet le nom exact du paquet contenant le compilateur g++. Me conduisant à cette page: https://superuser.com/questions/590808/yum-install-gcc-g-doesnt-work-anymore-in-centos-6-4

 node]$ sudo yum install gcc-c++ node]$ ./configure --prefix=/opt/node-v8.1.1/ && echo okok

 node]$ make -j9 && echo okok

 node]$ sudo make install && echo okok

 node]$ /opt/node/bin/node --versionv8.1.1

Succès. Encore une fois.

C.Apporter des modifications au logiciel installé à partir du code source

Vous pouvez installer le logiciel à partir de la source parce que vous avez besoin d’une version très spécifique non disponible dans votre référentiel de distribution, ou parce que vous souhaitez modifier le programme pour corriger un bug ou ajouter une fonctionnalité. Après tout, l’open-source consiste à apporter des modifications. Je vais donc profiter de cette occasion pour vous donner un avant-goût du pouvoir que vous avez à portée de main maintenant que vous êtes capable de compiler votre propre logiciel.

Ici, nous allons apporter une modification mineure aux sources de NodeJS. Et nous verrons si notre changement sera incorporé dans la version compilée du logiciel:

Ouvrez le fichier node/src/node.cc dans votre éditeur de texte préféré (vim, nano, gedit, …). Et essayez de localiser ce fragment de code:

 if (debug_options.ParseOption(argv, arg)) { // Done, consumed by DebugOptions::ParseOption(). } else if (strcmp(arg, "--version") == 0 || strcmp(arg, "-v") == 0) { printf("%s\n", NODE_VERSION); exit(0); } else if (strcmp(arg, "--help") == 0 || strcmp(arg, "-h") == 0) { PrintHelp(); exit(0); }

Il se trouve autour de la ligne 3830 du fichier. Modifiez ensuite la ligne contenant printf pour qu’elle corresponde à celle-ci à la place:

 printf("%s (compiled by myself)\n", NODE_VERSION);

Retournez ensuite à votre terminal. Avant d’aller plus loin — et pour vous donner un aperçu de la puissance derrière git — vous pouvez vérifier si vous avez modifié le bon fichier:

diff --git a/src/node.cc b/src/node.ccindex bbce1022..a5618b57 100644--- a/src/node.cc+++ b/src/node.cc@@ -3828,7 +3828,7 @@ static void ParseArgs(int* argc, if (debug_options.ParseOption(argv, arg)) { // Done, consumed by DebugOptions::ParseOption(). } else if (strcmp(arg, "--version") == 0 || strcmp(arg, "-v") == 0) {- printf("%s\n", NODE_VERSION);+ printf("%s (compiled by myself)\n", NODE_VERSION); exit(0); } else if (strcmp(arg, "--help") == 0 || strcmp(arg, "-h") == 0) { PrintHelp();

Vous devriez voir un « -” (signe moins) avant la ligne telle qu’elle était avant de la changer. Et un « + » (signe plus) avant la ligne après vos modifications.

Il est maintenant temps de recompiler et de réinstaller votre logiciel:

make -j9 && sudo make install && echo okok

Cette fois, la seule raison pour laquelle il pourrait échouer est que vous avez fait une faute de frappe en changeant le code. Si tel est le cas, rouvrez le fichier node/src/node.cc dans votre éditeur de texte et corrigez l’erreur.

Une fois que vous aurez réussi à compiler et installer cette nouvelle version modifiée de NodeJS, vous pourrez vérifier si vos modifications ont bien été intégrées au logiciel :

:~/node$ /opt/node/bin/node --versionv8.1.1 (compiled by myself)

Félicitations! Vous avez fait votre première modification à un programme open source !

D. Laissez le shell localiser notre logiciel de construction personnalisé

Vous avez peut-être remarqué que j’ai toujours lancé mon logiciel NodeJS nouvellement compilé en spécifiant le chemin absolu vers le fichier binaire.

/opt/node/bin/node

Cela fonctionne. Mais c’est pour le moins ennuyeux. Il y a en fait deux façons courantes de résoudre ce problème.

Il existe en fait deux façons courantes de résoudre le problème gênant de spécifier le chemin absolu vers les fichiers binaires,
mais pour les comprendre, vous devez d’abord savoir que votre shell localise les fichiers exécutables en les recherchant uniquement dans les répertoires spécifiés par la variable d’environnement PATH.

:~/node$ echo $PATH/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Ici, sur ce système Debian, si vous ne spécifiez pas explicitement de répertoire dans le nom d’une commande, le shell recherchera d’abord les programmes exécutables dans /usr/local/bin, puis s’il n’est pas trouvé dans /usr/bin, puis s’il n’est pas trouvé dans /bin puis s’il n’est pas trouvé dans /usr/local/games puis s’il n’est pas trouvé dans /usr/games, alors s’il n’est pas trouvé … le shell signalera une erreur « commande introuvable”.

Étant donné que, nous avons deux façons de rendre une commande accessible au shell: en l’ajoutant à l’un des répertoires PATH déjà configurés. Ou en ajoutant le répertoire contenant notre fichier exécutable au PATH.

Ajouter un lien depuis /usr/local/bin

Simplement copier l’exécutable binaire du nœud de /opt/node/bin vers /usr/local/bin serait une mauvaise idée car ce faisant, le programme exécutable ne serait plus en mesure de localiser les autres composants requis appartenant à /opt/node/ div> (c’est une pratique courante pour un logiciel de localiser ses fichiers de ressources par rapport à son propre emplacement).

Ainsi, la façon traditionnelle de le faire est d’utiliser un lien symbolique:

:~/node$ sudo ln -sT /opt/node/bin/node /usr/local/bin/node:~/node$ which -a node || echo not found/usr/local/bin/node:~/node$ node --versionv8.1.1 (compiled by myself)

C’est une solution simple et efficace, surtout si un progiciel est composé de quelques programmes exécutables bien connus — car vous devez créer un lien symbolique pour chaque commande invokable par l’utilisateur. Par exemple, si vous connaissez NodeJS, vous connaissez l’application compagnon npm Je devrais également créer un lien symbolique à partir de /usr/local/bin. Mais je vous laisse cela comme un exercice.

Modification du CHEMIN

Tout d’abord, si vous avez essayé la solution précédente, supprimez le lien symbolique du nœud créé précédemment pour partir d’un état clair :

:~/node$ sudo rm /usr/local/bin/node:~/node$ which -a node || echo not foundnot found

Et maintenant, voici la commande magique pour changer votre PATH:

:~/node$ export PATH="/opt/node/bin:${PATH}":~/node$ echo $PATH/opt/node/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Simplement dit, j’ai remplacé le contenu de la variable d’environnement PATH par son contenu précédent, mais préfixé par /opt/node/bin. Ainsi, comme vous pouvez l’imaginer maintenant, le shell regardera d’abord dans le répertoire /opt/node/bin pour les programmes exécutables. Nous pouvons confirmer qu’en utilisant la commande which :

:~/node$ which -a node || echo not found/opt/node/bin/node:~/node$ node --versionv8.1.1 (compiled by myself)

Alors que la solution « link” est permanente dès que vous avez créé le lien symbolique dans /usr/local/bin, la PATH change n’est efficace que dans le shell actuel. Je vous laisse faire quelques recherches sur la façon d’apporter des modifications aux permanents PATH. Comme un indice, cela a à voir avec votre « profil ». Si vous trouvez la solution, n’hésitez pas à la partager avec les autres lecteurs en utilisant la section commentaire ci-dessous!

E. Comment supprimer ce logiciel nouvellement installé du code source

Étant donné que notre logiciel NodeJS compilé personnalisé se trouve complètement dans le répertoire /opt/node-v8.1.1, la suppression de ce logiciel ne nécessite pas plus d’effort que d’utiliser la commande rm pour supprimer ce répertoire:

sudo rm -rf /opt/node-v8.1.1

ATTENTION: sudo

> et rm -rf sont un cocktail dangereux! Vérifiez toujours votre commande deux fois avant d’appuyer sur la touche « entrée”. Vous n’aurez aucun message de confirmation et aucune restauration si vous supprimez le mauvais répertoire

Ensuite, si vous avez modifié votre PATH, vous devrez annuler ces modifications, ce qui n’est pas compliqué du tout.

Et si vous avez créé des liens à partir de /usr/local/binvous devrez tous les supprimer:

:~/node$ sudo find /usr/local/bin \ -type l \ -ilname "/opt/node/*" \ -print -delete/usr/local/bin/node

Attendez? Où était l’enfer de la dépendance ?

En guise de commentaire final, si vous avez lu sur la compilation de votre propre logiciel personnalisé, vous avez peut-être entendu parler de l’enfer des dépendances. C’est un surnom pour cette situation ennuyeuse où avant de pouvoir compiler avec succès un logiciel, vous devez d’abord compiler une bibliothèque pré-requise, qui à son tour nécessite une autre bibliothèque qui pourrait à son tour être incompatible avec un autre logiciel que vous avez déjà installé.

Une partie du travail des responsables de paquets de votre distribution consiste à résoudre réellement cet enfer de dépendance et à s’assurer que les différents logiciels de votre système utilisent des bibliothèques compatibles et sont installés dans le bon ordre.

Pour cet article, j’ai choisi exprès d’installer NodeJS car il n’a pratiquement pas de dépendances. J’ai dit « virtuellement » car, en fait, il a des dépendances. Mais le code source de ces dépendances est présent dans le référentiel source du projet (dans le sous-répertoire node/deps), vous n’avez donc pas besoin de les télécharger et de les installer manuellement.