Comment installer un logiciel à partir du code source… et le supprimer ensuite

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

L'une des plus grandes forces de votre distribution Linux est son gestionnaire de packages et le référentiel de logiciels 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 entièrement automatisée.

Mais malgré tous leurs efforts, les responsables du paquet ne peuvent pas gérer tous les cas d'utilisation. Ils ne peuvent pas non plus regrouper tous les logiciels disponibles. Il existe 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, pour laquelle je dois compiler un logiciel 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 sophistiquées.

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 un logiciel à partir du code source pour la première fois peut 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.

[irp posts=»13491″ name=»Comment installer et supprimer des logiciels dans Ubuntu »]

A. Installation de logiciels à 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 depuis 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 se trouvent 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, conserver cet historique présente de nombreux avantages. Pour nous aujourd'hui, le principal est que nous serons en mesure d'obtenir les sources du projet telles qu'elles étaient à un moment donné. Plus précisément, je pourrai récupérer les sources telles qu'elles étaient lors de la sortie de la version 8.1.1 que je souhaite. Même s'il y a eu de nombreuses modifications depuis.

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 garder une trace des événements importants dans l'historique du projet, comme lorsqu'ils commencent à travailler sur une nouvelle fonctionnalité ou lorsqu'ils publient une version. Je ne rentrerai pas dans les détails ici, tout ce que vous devez savoir c'est que je recherche la version taguée "v8.1.1"

Après avoir choisi la balise "v8.1.1", la page est actualisée, le changement le plus évident étant que la balise apparaît désormais dans le cadre de l'URL. De plus, vous remarquerez que la date de modification du fichier est également différente. L'arborescence source que vous voyez maintenant est celle qui existait au moment où la balise v8.1.1 a été créée. Dans un certain sens, vous pouvez considérer un outil de contrôle de version comme git comme une machine à voyager dans le temps, vous permettant d'aller et venir 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 les besoins de l'explication. Mais si vous préférez utiliser un outil graphique, n'hésitez pas à le faire :

wget https://github.com/nodejs/node/archive/v8.1.1.zip
unzip v8.1.1.zip
cd 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 suggérerais d'utiliser directement le git outil 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 system
sh$ sudo apt-get install git
# Make a shallow clone the NodeJS repository at v8.1.1
sh$ git clone --depth 1 \
              --branch v8.1.1 \
              https://github.com/nodejs/node
sh$ 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.

Quoi qu'il en soit, chaque fois que vous avez téléchargé la source en utilisant git ou sous forme d'archive ZIP, vous devriez maintenant avoir exactement les mêmes fichiers source dans le répertoire courant :

sh$ ls
android-configure  BUILDING.md            common.gypi      doc            Makefile   src
AUTHORS            CHANGELOG.md           configure        GOVERNANCE.md  node.gyp   test
benchmark          CODE_OF_CONDUCT.md     CONTRIBUTING.md  lib            node.gypi  tools
BSDmakefile        COLLABORATOR_GUIDE.md  deps             LICENSE        README.md  vcbuild.bat

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

On parle habituellement de « compiler les sources », mais la compilation n'est qu'une des phases nécessaires 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 en émettant simplement 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 y a une liste presque interminable 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.

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 ajuster 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 configure Le fichier est un script spécifique au projet qui vérifiera la configuration du système de destination et les fonctionnalités disponibles 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'une configure typique le travail consiste à construire le Makefile . C'est le fichier contenant les instructions nécessaires pour construire efficacement le projet.

Le make tool, d'autre part, est un outil POSIX disponible sur n'importe quel système de type Unix. Il lira le Makefile spécifique au projet et effectuez les opérations requises pour créer et installer votre programme.

Mais, comme toujours dans le monde Linux, vous disposez toujours d'une certaine indulgence pour personnaliser la version en fonction de vos besoins spécifiques.

./configure --help

Le configure -help La commande 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 la signification de chaque option de configuration.

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

[irp posts=»14419″ name=»8 trucs et astuces Vim qui feront de vous un utilisateur pro »]

Étape 3 :Le FHS

La hiérarchie du système de fichiers Linux sur une distribution typique est principalement conforme au Filesystem Hierarchy Standard (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 GNU Autotools - et la plupart des autres systèmes de construction - l'emplacement d'installation par défaut de votre nouveau logiciel sera /usr/local . Lequel est un bon choix car selon le FSH « La hiérarchie /usr/local est destinée à être utilisée par l'administrateur système lors de l'installation de logiciels localement ? Il doit être protégé contre l'écrasement lors de la mise à jour du logiciel système. 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. »

Le /usr/local hiérarchie 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, etc.

Le seul problème lors de l'utilisation de /usr/local l'arborescence 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 /opt sous-arbre à la place. Encore une fois, pour citer le FHS :

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

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

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

sh$ sudo mkdir /opt/node-v8.1.1
sh$ 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.1
sh$ 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" après le make La commande est terminée signifierait qu'il y a eu une erreur pendant le processus de construction. Comme nous avons exécuté une construction parallèle à cause du -j option, 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 le -j choix 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 lançant la commande :

sh$ sudo make install

Et testez-le :

sh$ /opt/node/bin/node --version
v8.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 "instructions 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 des sources, il peut être utile de prendre le temps d'étudier certains problèmes courants. Donc, je vais refaire toute la procédure, mais cette fois à partir de systèmes Debian 9.0 et CentOS 7.0 frais et minimaux afin que vous puissiez voir les erreurs que j'ai rencontrées et comment je les ai résolues.

À partir de Debian 9.0 "Étirement"

[email protected]:~$ 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. Installez simplement le git paquet :

[email protected]:~$ sudo apt-get install git

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

[email protected]:~/node$ sudo mkdir /opt/node-v8.1.1
[email protected]:~/node$ sudo ln -sT node-v8.1.1 /opt/node

Pas de problème ici.

[email protected]:~/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 langage C++, nous avons besoin d'un compilateur C++. Ici, je vais installer `g++`, le compilateur GNU C++ à cet effet :

[email protected]:~/node$ sudo apt-get install g++
[email protected]:~/node$ ./configure --prefix=/opt/node-v8.1.1/ && echo ok
[...]
ok

[email protected]:~/node$ make -j9 && echo ok
-bash: make: command not found

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

[email protected]:~/node$ sudo apt-get install make
[email protected]:~/node$ make -j9 && echo ok
[...]
ok

[email protected]:~/node$ sudo make install
[...]
[email protected]:~/node$ /opt/node/bin/node --version
v8.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 pour 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 certains ou tous les outils typiques utilisés pour compiler un logiciel. Sur les systèmes basés sur Debian, vous rencontrerez probablement le paquet build-essentials à cet effet. Et sur les distributions basées sur Red-Hat, ce seront les "Outils de développement" groupe.

De CentOS 7.0

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

Commande non trouvée? Installez-le simplement en utilisant le yum gestionnaire de paquets :

[[email protected] ~]$ sudo yum install git

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

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

[[email protected] ~]$ cd node
[[email protected] 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 langage C++, mais mon système n'a pas le compilateur correspondant. Miam à la rescousse. Comme je ne suis pas un utilisateur régulier de CentOS, j'ai dû chercher sur Internet le nom exact du paquet contenant le compilateur g++. Me menant à cette page :https://superuser.com/questions/590808/yum-install-gcc-g-doesnt-work-anymore-in-centos-6-4

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

[[email protected] node]$ make -j9 && echo ok
[...]
ok

[[email protected] node]$ sudo make install && echo ok
[...]
ok

[[email protected] node]$ /opt/node/bin/node --version
v8.1.1

Succès. Encore une fois.

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

Vous pouvez installer un 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 bogue 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 de la puissance dont vous disposez 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 intégré 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[0], 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);
    }

C'est autour de la ligne 3830 du fichier. Modifiez ensuite la ligne contenant printf pour faire correspondre celui-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 de git, vous pouvez vérifier si vous avez modifié le bon fichier :

diff --git a/src/node.cc b/src/node.cc
index 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[0], 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 que vous ne la changiez. 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 ok
[...]
ok

Cette fois, la seule raison pour laquelle cela pourrait échouer est que vous avez fait une faute de frappe en modifiant le code. Si tel est le cas, rouvrez le node/src/node.cc fichier 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 :

[email protected]:~/node$ /opt/node/bin/node --version
v8.1.1 (compiled by myself)

Toutes nos félicitations! Vous venez d'apporter votre première modification à un programme open source !

D. Laissez le shell localiser notre logiciel de build 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

Ça marche. Mais c'est ennuyeux, c'est le moins qu'on puisse dire. Il existe 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 ennuyeux de spécifier le chemin absolu vers les fichiers binaires,
mais pour les comprendre il faut 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.

[email protected]:~/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 cadre d'un nom de commande, le shell recherchera d'abord les programmes exécutables dans /usr/local/bin , alors s'il n'est pas trouvé dans /usr/bin , alors s'il n'est pas trouvé dans /bin alors s'il n'est pas trouvé dans /usr/local/games alors 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é cela, nous avons deux façons de rendre une commande accessible au shell :en l'ajoutant à l'un des PATH déjà configurés répertoires. Soit en ajoutant le répertoire contenant notre fichier exécutable au PATH .

Ajout d'un lien depuis /usr/local/bin

Juste copier l'exécutable binaire du nœud depuis /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/ (c'est une pratique courante pour un logiciel de localiser ses fichiers de ressources par rapport à son propre emplacement).

Donc, la manière traditionnelle de le faire est d'utiliser un lien symbolique :

[email protected]:~/node$ sudo ln -sT /opt/node/bin/node /usr/local/bin/node
[email protected]:~/node$ which -a node || echo not found
/usr/local/bin/node
[email protected]:~/node$ node --version
v8.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 invocable par l'utilisateur. Par exemple, si vous êtes familier avec NodeJS, vous connaissez le npm application compagnon je devrais créer un lien symbolique depuis /usr/local/bin aussi. Mais je vous laisse cela comme exercice.

Modifier le PATH

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

[email protected]:~/node$ sudo rm /usr/local/bin/node
[email protected]:~/node$ which -a node || echo not found
not found

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

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

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

[email protected]:~/node$ which -a node || echo not found
/opt/node/bin/node
[email protected]:~/node$ node --version
v8.1.1 (compiled by myself)

Alors que la solution "lien" est permanente dès que vous avez créé le lien symbolique dans /usr/local/bin , le PATH le changement n'est effectif que dans le shell actuel. Je vous laisse faire quelques recherches sur la façon d'apporter des modifications dans le PATH permanents. À titre indicatif, 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 des commentaires ci-dessous !

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

Étant donné que notre logiciel NodeJS compilé personnalisé se trouve entièrement dans le /opt/node-v8.1.1 répertoire, la suppression de ce logiciel ne nécessite pas plus d'efforts 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 depuis /usr/local/bin vous devrez tous les supprimer :

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

Attendre ? Où était l'Enfer des Dépendances ?

Comme dernier commentaire, si vous lisez comment compiler 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 réussir à compiler 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 d'autres logiciels que vous avez déjà installé.

Une partie du travail des mainteneurs de paquets de votre distribution consiste à résoudre cet enfer de dépendances 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" parce qu'en fait, il a dépendances. Mais le code source de ces dépendances est présent dans le référentiel source du projet (dans le node/deps sous-répertoire), vous n'avez donc pas besoin de les télécharger et de les installer manuellement au préalable.

Mais si vous souhaitez en savoir plus sur ce problème et apprendre à le résoudre, faites-le moi savoir en utilisant la section des commentaires ci-dessous :ce serait un excellent sujet pour un article plus avancé !