Come installare il software dal codice sorgente... e rimuoverlo in seguito

Breve:questa guida dettagliata spiega come installare un programma dal codice sorgente in Linux e come rimuovere il software installato dal codice sorgente.

Uno dei maggiori punti di forza della tua distribuzione Linux è il suo gestore di pacchetti e il repository software associato. Con loro, hai tutti gli strumenti e le risorse necessarie per scaricare e installare nuovo software sul tuo computer in modo completamente automatizzato.

Ma nonostante tutti i loro sforzi, i manutentori del pacchetto non possono gestire tutti i casi d'uso. Né possono impacchettare tutto il software disponibile là fuori. Quindi ci sono ancora situazioni in cui dovrai compilare e installare nuovo software da solo. Per quanto mi riguarda, il motivo di gran lunga più comune per cui devo compilare alcuni software è quando devo eseguire una versione molto specifica o modificare il codice sorgente utilizzando alcune opzioni di compilazione fantasiose.

Se le tue esigenze appartengono a quest'ultima categoria, è probabile che tu sappia già cosa fare. Ma, per la stragrande maggioranza degli utenti Linux, la compilazione e l'installazione di software dal codice sorgente per la prima volta potrebbe sembrare una cerimonia di iniziazione:alquanto spaventosa; ma con la promessa di entrare in un nuovo mondo di possibilità e un posto di prestigio in una comunità privilegiata.

[irp posts=”13491″ name=”Come installare e rimuovere software in Ubuntu”]

A. Installazione del software dal codice sorgente in Linux

Ed è esattamente quello che faremo qui. Ai fini di questo articolo, diciamo che devo installare NodeJS 8.1.1 sul mio sistema. Esattamente quella versione. Una versione che non è disponibile dal repository 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

Ora, l'installazione di NodeJs su Ubuntu o Debian è piuttosto semplice se lo fai con il gestore di pacchetti. Ma facciamolo tramite il codice sorgente.

Fase 1:ottenere il codice sorgente da GitHub

Come molti progetti open source, i sorgenti di NodeJS possono essere trovati su GitHub:https://github.com/nodejs/node

Quindi, andiamo direttamente lì.

Se non hai familiarità con GitHub, git o qualsiasi altro sistema di controllo della versione degno di nota, il repository contiene la fonte corrente del software, oltre a una cronologia di tutte le modifiche apportate nel corso degli anni a quel software. Alla fine fino alla prima riga scritta per quel progetto. Per gli sviluppatori, mantenere quella storia ha molti vantaggi. Per noi oggi, il principale è che saremo in grado di ottenere le fonti per il progetto come erano in un dato momento. Più precisamente, sarò in grado di ottenere i sorgenti come erano quando è stata rilasciata la versione 8.1.1 che desidero. Anche se da allora ci sono state molte modifiche.

Su GitHub, puoi utilizzare il pulsante "ramo" per navigare tra le diverse versioni del software. "Ramo" e "tag" sono concetti in qualche modo correlati in Git. Fondamentalmente, gli sviluppatori creano "rami" e "tag" per tenere traccia di eventi importanti nella cronologia del progetto, come quando iniziano a lavorare su una nuova funzionalità o quando pubblicano una versione. Non entrerò nei dettagli qui, tutto quello che devi sapere è che sto cercando la versione taggata "v8.1.1"

Dopo aver scelto il tag "v8.1.1", la pagina viene aggiornata, la modifica più evidente è che il tag ora appare come parte dell'URL. Inoltre, noterai che anche la data di modifica del file è diversa. L'albero dei sorgenti che stai vedendo è quello che esisteva al momento della creazione del tag v8.1.1. In un certo senso, puoi pensare a uno strumento di controllo della versione come git come a una macchina per viaggiare nel tempo, che ti consente di andare avanti e indietro nella cronologia di un progetto.

A questo punto, possiamo scaricare i sorgenti di NodeJS 8.1.1. Non può mancare il grande pulsante blu che suggerisce di scaricare l'archivio ZIP del progetto. Per quanto mi riguarda, scaricherò ed estrarrò lo ZIP dalla riga di comando per motivi di spiegazione. Ma se preferisci utilizzare uno strumento GUI, non esitare a farlo invece:

wget https://github.com/nodejs/node/archive/v8.1.1.zip
unzip v8.1.1.zip
cd node-8.1.1/

Il download dell'archivio ZIP funziona benissimo. Ma se vuoi farlo “come un professionista”, ti suggerisco di usare direttamente il git strumento per scaricare i sorgenti. Non è affatto complicato e sarà un bel primo contatto con uno strumento che incontrerai spesso:

# 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/

A proposito, se hai un problema, considera la prima parte di questo articolo come un'introduzione generale. In seguito avrò spiegazioni più dettagliate per le distribuzioni basate su Debian e RedHat per aiutarti a risolvere i problemi comuni.

Ad ogni modo, ogni volta che hai scaricato il sorgente usando git o come archivio ZIP, ora dovresti avere esattamente gli stessi file di origine nella directory corrente:

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

Fase 2:Comprensione del sistema di build del programma

Di solito si parla di “compilazione dei sorgenti”, ma la compilazione è solo una delle fasi necessarie per produrre un software funzionante a partire dal suo sorgente. Un sistema di compilazione è un insieme di strumenti e pratiche utilizzati per automatizzare e articolare queste diverse attività al fine di creare interamente il software semplicemente emettendo pochi comandi.

Se il concetto è semplice, la realtà è un po' più complicata. Perché diversi progetti o linguaggi di programmazione possono avere requisiti diversi. O per i gusti del programmatore. O le piattaforme supportate. O per ragioni storiche. Oppure... oppure... c'è un elenco quasi infinito di motivi per scegliere o creare un altro sistema di build. Tutto questo per dire che ci sono molte soluzioni diverse utilizzate là fuori.

NodeJS utilizza un sistema di build in stile GNU, è una scelta popolare nella comunità open source e, ancora una volta, un buon modo per iniziare il tuo viaggio.

Scrivere e mettere a punto un sistema di compilazione è un compito piuttosto complesso, ma per l'"utente finale", i sistemi di compilazione in stile GNU semplificano il compito utilizzando due strumenti:configure e make .

Il configure file è uno script specifico del progetto che verificherà la configurazione del sistema di destinazione e le funzionalità disponibili per garantire che il progetto possa essere costruito, affrontando eventualmente le specificità della piattaforma corrente.

Una parte importante di una tipica configure il lavoro è costruire il Makefile . Questo è il file contenente le istruzioni necessarie per costruire efficacemente il progetto.

Il make strumento, d'altra parte, è uno strumento POSIX disponibile su qualsiasi sistema simile a Unix. Leggerà il Makefile specifico del progetto ed eseguire le operazioni richieste per creare e installare il programma.

Ma, come sempre nel mondo Linux, hai ancora una certa clemenza nel personalizzare la build in base alle tue esigenze specifiche.

./configure --help

Il configure -help comando ti mostrerà tutte le opzioni di configurazione disponibili. Ancora una volta, questo è molto specifico del progetto. E ad essere onesti, a volte è necessario approfondire il progetto prima di comprendere appieno il significato di ogni singola opzione di configurazione.

Ma c'è almeno un'opzione standard di GNU Autotools che devi conoscere:il --prefix opzione. Questo ha a che fare con la gerarchia del file system e il luogo in cui verrà installato il software.

[irp posts=”14419″ name=”8 consigli e trucchi Vim che ti faranno diventare un utente professionista”]

Fase 3:L'FHS

La gerarchia del file system Linux su una distribuzione tipica è per lo più conforme al Filesystem Hierarchy Standard (FHS)

Quello standard spiega lo scopo delle varie directory del tuo sistema:/usr , /tmp , /var e così via.

Quando si utilizza GNU Autotools e la maggior parte degli altri sistemi di build, il percorso di installazione predefinito per il nuovo software sarà /usr/local . Qual è una buona scelta in quanto secondo FSH “La gerarchia /usr/local deve essere utilizzata dall'amministratore di sistema durante l'installazione del software in locale? Deve essere protetto dalla sovrascrittura durante l'aggiornamento del software di sistema. Può essere utilizzato per programmi e dati condivisibili tra un gruppo di host, ma non presenti in /usr."

Il /usr/local gerarchia replica in qualche modo la directory principale e lì troverai /usr/local/bin per i programmi eseguibili, /usr/local/lib per le librerie, /usr/local/share per file indipendenti dall'architettura e così via.

L'unico problema quando si utilizza /usr/local l'albero per l'installazione del software personalizzato è che i file per tutto il software verranno mixati lì. In particolare, dopo aver installato un paio di software, sarà difficile risalire a quale file esattamente di /usr/local/bin e /usr/local/lib appartiene a quale software. Tuttavia, ciò non causerà alcun problema al sistema. Dopotutto, /usr/bin è più o meno lo stesso pasticcio. Ma questo diventerà un problema il giorno in cui vorrai rimuovere un software installato manualmente.

Per risolvere questo problema, di solito preferisco installare software personalizzato in /opt sottoalbero invece. Ancora una volta, per citare l'FHS:

_”/opt è riservato all'installazione di pacchetti software applicativi aggiuntivi.

Un pacchetto da installare in /opt deve individuare i suoi file statici in un albero di directory /opt/ o /opt/ separato, dove è un nome che descrive il pacchetto software e è il il nome registrato LANANA del provider.”_

Quindi creeremo una sottodirectory di /opt specificamente per la nostra installazione personalizzata di NodeJS. E se un giorno vorrò rimuovere quel software, dovrò semplicemente rimuovere quella directory:

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.

Tutto tranne "ok" dopo il make comando è stato completato significherebbe che si è verificato un errore durante il processo di compilazione. Poiché abbiamo eseguito una build parallela a causa di -j opzione, non è sempre facile recuperare il messaggio di errore dato il grande volume di output prodotto dal sistema di compilazione.

In caso di problemi, riavvia semplicemente make , ma senza -j opzione questa volta. E l'errore dovrebbe apparire verso la fine dell'output:

sh$ make

Infine, una volta che la compilazione è terminata, puoi installare il tuo software nella sua posizione eseguendo il comando:

sh$ sudo make install

E provalo:

sh$ /opt/node/bin/node --version
v8.1.1

B. Cosa succede se le cose vanno storte durante l'installazione dal codice sorgente?

Quello che ho spiegato sopra è principalmente ciò che puoi vedere nella pagina "istruzioni di compilazione" di un progetto ben documentato. Ma dato che l'obiettivo di questo articolo è quello di consentirti di compilare il tuo primo software dalle fonti, potrebbe valere la pena dedicare del tempo a indagare su alcuni problemi comuni. Quindi, eseguirò di nuovo l'intera procedura, ma questa volta da un sistema Debian 9.0 e CentOS 7.0 fresco e minimale in modo da poter vedere gli errori che ho riscontrato e come li ho risolti.

Da Debian 9.0 “Stretch”

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

Questo problema è abbastanza facile da diagnosticare e risolvere. Basta installare git pacchetto:

[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

Nessun problema qui.

[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.

Ovviamente, per compilare un progetto, è necessario un compilatore. Essendo NodeJS scritto usando il linguaggio C++, abbiamo bisogno di un compilatore C++. Qui installerò `g++`, il compilatore GNU C++ per questo scopo:

[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 altro strumento mancante. Stessi sintomi. Stessa soluzione:

[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

Successo!

Nota:ho installato i vari strumenti uno per uno per mostrare come diagnosticare i problemi di compilazione e per mostrarti la soluzione tipica per risolverli. Ma se cerchi maggiori informazioni sull'argomento o leggi altri tutorial, scoprirai che la maggior parte delle distribuzioni ha "meta-pacchetti" che fungono da ombrello per installare alcuni o tutti gli strumenti tipici utilizzati per la compilazione di un software. Sui sistemi basati su Debian, probabilmente incontrerai il pacchetto build-essentials per quello scopo. E sulle distribuzioni basate su Red Hat, saranno gli "Strumenti di sviluppo" gruppo.

Da CentOS 7.0

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

Comando non trovato? Installalo usando yum gestore dei pacchetti:

[[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.

Indovinate:NodeJS è scritto usando il linguaggio C++, ma il mio sistema non ha il compilatore corrispondente. Yum in soccorso. Dato che non sono un normale utente CentOS, in realtà ho dovuto cercare su Internet il nome esatto del pacchetto contenente il compilatore g++. Conducendomi a quella pagina: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

Successo. Di nuovo.

C. Apportare modifiche al software installato dal codice sorgente

È possibile installare il software dal sorgente perché è necessaria una versione molto specifica non disponibile nel repository di distribuzione o perché si desidera modificare il programma per correggere un bug o aggiungere una funzionalità. Dopotutto, l'open source consiste nel fare modifiche. Quindi, colgo l'occasione per darti un assaggio del potere che hai a portata di mano ora che sei in grado di compilare il tuo software.

Qui faremo una piccola modifica ai sorgenti di NodeJS. E vedremo se la nostra modifica verrà incorporata nella versione compilata del software:

Apri il file node/src/node.cc nel tuo editor di testo preferito (vim, nano, gedit, …). E prova a individuare quel frammento di codice:

   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);
    }

È intorno alla riga 3830 del file. Quindi modifica la riga contenente printf per abbinare quello invece:

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

Quindi torna al tuo terminale. Prima di andare oltre, e per darti un'idea in più del potere dietro git, puoi controllare se hai modificato il file giusto:

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();

Dovresti vedere un "-" (segno meno) prima della riga com'era prima di modificarla. E un "+" (segno più) prima della riga dopo le modifiche.

È giunto il momento di ricompilare e reinstallare il software:

make -j9 && sudo make install && echo ok
[...]
ok

Questa volta, l'unico motivo per cui potrebbe fallire è che hai commesso un errore di battitura durante la modifica del codice. In questo caso, riapri il node/src/node.cc file nel tuo editor di testo e correggi l'errore.

Una volta che sei riuscito a compilare e installare quella nuova versione modificata di NodeJS, sarai in grado di verificare se le tue modifiche sono state effettivamente incorporate nel software:

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

Congratulazioni! Hai apportato la tua prima modifica a un programma open source!

D. Lascia che sia la shell a individuare il nostro software di build personalizzato

Potresti aver notato che ho sempre avviato il mio software NodeJS appena compilato specificando il percorso assoluto del file binario.

/opt/node/bin/node

Funziona. Ma questo è fastidioso, per non dire altro. In realtà ci sono due modi comuni per risolverlo.

Esistono in realtà due modi comuni per risolvere il fastidioso problema di specificare il percorso assoluto dei file binari,
ma per capirli devi prima sapere che la tua shell individua i file eseguibili cercandoli solo nelle directory specificate dalla variabile d'ambiente PATH.

[email protected]:~/node$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Qui, su quel sistema Debian, se non specifichi esplicitamente alcuna directory come parte del nome di un comando, la shell cercherà prima i programmi eseguibili in /usr/local/bin , se non trovato in /usr/bin , se non lo trovi in ​​/bin quindi se non lo trovi in ​​/usr/local/games quindi se non lo trovi in ​​/usr/games , quindi se non trovato... la shell riporterà un errore "comando non trovato" .

Detto questo, abbiamo due modi per rendere accessibile un comando alla shell:aggiungendolo a uno dei PATH già configurati directory. Oppure aggiungendo la directory contenente il nostro file eseguibile al PATH .

Aggiunta di un collegamento da /usr/local/bin

Basta copiare l'eseguibile binario del nodo da /opt/node/bin a /usr/local/bin sarebbe una cattiva idea poiché così facendo il programma eseguibile non sarebbe più in grado di individuare gli altri componenti richiesti appartenenti a /opt/node/ (è una pratica comune per il software individuare i propri file di risorse rispetto alla propria posizione).

Quindi, il modo tradizionale per farlo è usare un collegamento simbolico:

[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)

Questa è una soluzione semplice ed efficace, soprattutto se un pacchetto software è composto solo da pochi programmi eseguibili noti, poiché è necessario creare un collegamento simbolico per ogni comando richiamabile dall'utente. Ad esempio, se hai familiarità con NodeJS, conosci il npm applicazione complementare dovrei collegare simbolicamente da /usr/local/bin anche. Ma te lo lascio come esercizio.

Modifica del PERCORSO

Innanzitutto, se hai provato la soluzione precedente, rimuovi il collegamento simbolico del nodo creato in precedenza per iniziare da uno stato chiaro:

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

E ora, ecco il comando magico per cambiare il tuo 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

Detto semplicemente, ho sostituito il contenuto del PATH variabile di ambiente in base al suo contenuto precedente, ma preceduta da /opt/node/bin . Quindi, come puoi immaginare ora, la shell cercherà prima in /opt/node/bin directory per i programmi eseguibili. Possiamo confermarlo usando il which comando:

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

Considerando che la soluzione "link" è permanente non appena hai creato il collegamento simbolico in /usr/local/bin , il PATH la modifica è efficace solo nella shell corrente. Ti lascio a fare qualche ricerca su come apportare modifiche al PATH permanenti. Come suggerimento, ha a che fare con il tuo "profilo". Se trovi la soluzione, non esitare a condividerla con gli altri lettori utilizzando la sezione commenti qui sotto!

E. Come rimuovere il software appena installato dal codice sorgente

Poiché il nostro software NodeJS compilato su misura si trova completamente in /opt/node-v8.1.1 directory, la rimozione di quel software non richiede uno sforzo maggiore rispetto all'utilizzo del comando rm per rimuovere quella directory:

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

ATTENZIONE: sudo e rm -rf sono un cocktail pericoloso! Controlla sempre il tuo comando due volte prima di premere il tasto "invio". Non avrai alcun messaggio di conferma e nessun ripristino se rimuovi la directory sbagliata...

Quindi, se hai modificato il tuo PATH , dovrai annullare tali modifiche, il che non è affatto complicato.

E se hai creato link da /usr/local/bin dovrai rimuoverli tutti:

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

Aspetta? Dov'era l'inferno delle dipendenze?

Come commento finale, se leggi della compilazione del tuo software personalizzato, potresti aver sentito parlare dell'inferno delle dipendenze. Questo è un soprannome per quella fastidiosa situazione in cui prima di poter compilare con successo un software, devi prima compilare una libreria prerequisita, che a sua volta richiede un'altra libreria che potrebbe a sua volta essere incompatibile con qualche altro software che hai già installato.

Parte del lavoro dei gestori dei pacchetti della tua distribuzione è risolvere effettivamente quell'inferno di dipendenze e garantire che i vari software del tuo sistema utilizzino librerie compatibili e siano installati nell'ordine giusto.

Per questo articolo, ho scelto, apposta, di installare NodeJS poiché praticamente non ha dipendenze. Ho detto "virtualmente" perché, in effetti, ha dipendenze. Ma il codice sorgente di queste dipendenze è presente nel repository sorgente del progetto (in node/deps sottodirectory), quindi non è necessario scaricarli e installarli manualmente in anticipo.

Ma se sei interessato a capire di più su quel problema e imparare come affrontarlo, fammi sapere che usando la sezione commenti qui sotto:sarebbe un ottimo argomento per un articolo più avanzato!