scurt: acest ghid detaliat explică cum se instalează un program din Codul sursă în Linux și cum se elimină software-ul instalat din Codul sursă.

una dintre cele mai mari puteri ale distribuției Linux este managerul de pachete și depozitul de software asociat. Cu ei, aveți toate instrumentele și resursele necesare pentru a descărca și instala software nou pe computer într-un mod complet automatizat.

dar, în ciuda tuturor eforturilor lor, întreținătorii de pachete nu se pot ocupa de fiecare caz de utilizare. Nici nu pot pachet toate software-ul disponibil acolo. Deci, există încă situații în care va trebui să compilați și să instalați singur software nou. În ceea ce mă privește, cel mai frecvent motiv, de departe, trebuie să compilez un software este atunci când trebuie să rulez o versiune foarte specifică sau să modific codul sursă prin utilizarea unor opțiuni de compilare fanteziste.

dacă nevoile dvs. aparțin celei de-a doua categorii, este posibil să știți deja ce să faceți. Dar, pentru marea majoritate a utilizatorilor Linux, compilarea și instalarea software-ului din codul sursă pentru prima dată ar putea părea o ceremonie de inițiere: oarecum înspăimântătoare; dar cu promisiunea de a intra într-o nouă lume a posibilităților și un loc de prestigiu într-o comunitate privilegiată.

A. instalarea software-ului din codul sursă în Linux

și exact asta vom face aici. În scopul acestui articol, să presupunem că trebuie să instalez NodeJS 8.1.1 pe sistemul meu. Exact versiunea asta. O versiune care nu este disponibilă din depozitul 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

acum, instalarea NodeJs pe Ubuntu sau Debian este destul de simplă dacă o faceți cu managerul de pachete. Dar să o facem prin codul sursă.

Pasul 1: obținerea codului sursă de la GitHub

ca multe proiecte open-source, sursele NodeJS pot fi găsite pe GitHub:https://github.com/nodejs/node

deci, să mergem direct acolo.

dacă nu sunteți familiarizați cu GitHub, git sau orice alt sistem de control al versiunii care merită menționat, depozitul conține sursa curentă pentru software, precum și un istoric al dintre toate modificările făcute de-a lungul anilor la acel software. În cele din urmă până la prima linie scrisă pentru acel proiect. Pentru dezvoltatori, păstrarea acestei istorii are multe avantaje. Pentru noi astăzi, principala este că vom putea obține sursele pentru proiect așa cum au fost la un moment dat. Mai exact, voi putea obține sursele așa cum au fost atunci când versiunea 8.1.1 pe care o vreau a fost lansată. Chiar dacă au existat multe modificări de atunci.

pe GitHub, puteți utiliza butonul „ramură” pentru a naviga între diferite versiuni ale software-ului. „Sucursala” și „etichetele” sunt concepte oarecum legate în Git. Practic, dezvoltatorii creează „ramură” și „etichete” pentru a urmări evenimentele importante din istoricul proiectului, cum ar fi atunci când încep să lucreze la o nouă caracteristică sau când publică o versiune. Nu voi intra în detalii aici, tot ce trebuie să știți este că caut versiunea etichetată „v8.1.1”

după ce a ales pe „V8.1.1 ” tag, pagina este reîmprospătată, cea mai evidentă modificare fiind eticheta apare acum ca parte a adresei URL. În plus, veți observa că data schimbării fișierului este diferită. Arborele sursă pe care îl vedeți acum este cel care a existat la momentul creării etichetei v8.1.1. Într-un anumit sens, vă puteți gândi la un instrument de control al versiunii precum git ca la o mașină de călătorie în timp, permițându-vă să mergeți înainte și înapoi într-un istoric al proiectului.

În acest moment, putem descărca sursele de NodeJS 8.1.1. Nu puteți rata butonul albastru mare care sugerează descărcarea arhivei ZIP a proiectului. În ceea ce mă privește, voi descărca și extrage ZIP-ul din linia de comandă de dragul explicației. Dar dacă preferați să utilizați un instrument GUI, nu ezitați să faceți acest lucru în schimb:

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

descărcarea arhivei ZIP funcționează excelent. Dar dacă doriți să o faceți” ca un pro”, aș sugera să utilizați direct instrumentul git pentru a descărca sursele. Nu este deloc complicat— și va fi un prim contact frumos cu un instrument pe care îl veți întâlni adesea:

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

apropo, dacă aveți o problemă, luați în considerare prima parte a acestui articol ca o introducere generală. Mai târziu am Explicații mai detaliate pentru distribuțiile bazate pe Debian și RedHat pentru a vă ajuta să depanați problemele comune.

oricum, ori de câte ori ați descărcat sursa folosind git sau ca arhivă ZIP, ar trebui să aveți acum exact aceleași fișiere sursă în directorul curent:

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

Pasul 2: înțelegerea sistemului de construire a programului

de obicei vorbim despre „compilarea surselor”, dar compilarea este doar una dintre fazele necesar pentru a produce un software de lucru de la sursa sa. Un sistem build este un set de instrumente și practici utilizate pentru a automatiza și articula aceste sarcini diferite, în scopul de a construi în întregime software-ul doar prin emiterea de câteva comenzi.

dacă conceptul este simplu, realitatea este ceva mai complicată. Deoarece diferite proiecte sau limbaj de programare pot avea cerințe diferite. Sau din cauza gusturilor programatorului. Sau platformele acceptate. Sau din motive istorice. Sau … sau.. există o listă aproape nesfârșită de motive pentru a alege sau a crea un alt sistem de construire. Toate acestea pentru a spune că există multe soluții diferite utilizate acolo.

NodeJS folosește un sistem de construcție în stil GNU, este o alegere populară în comunitatea open source și, din nou, o modalitate bună de a vă începe călătoria.

scrierea și reglarea unui sistem de construire este o sarcină destul de complexă, dar pentru „utilizatorul final”, sistemele de construire în stil GNU ușurează sarcina folosind două instrumente:configure șimake.

fișierulconfigure este un script specific proiectului care va verifica configurația sistemului de destinație și caracteristica disponibilă pentru a se asigura că proiectul poate fi construit, în cele din urmă se ocupă de specificul platformei curente.

o parte importantă a unuiconfigure job este de a construiMakefile. Acesta este fișierul care conține instrucțiunile necesare pentru a construi eficient proiectul.

make instrumentul, pe de altă parte, este un instrument POSIX disponibil pe orice sistem de tip Unix. Acesta va citi proiectul specific Makefile și va efectua operațiunile necesare pentru a construi și instala programul.

dar, ca întotdeauna în lumea Linux, aveți încă o anumită clemență în personalizarea construirii la nevoile dvs. specifice.

./configure --help

comandaconfigure -help vă va arăta toate opțiunile de configurare disponibile. Încă o dată, acest lucru este foarte specific proiectului. Și pentru a fi sincer, uneori este necesar să săpați în proiect înainte de a înțelege pe deplin semnificația fiecărei opțiuni de configurare.

dar există cel puțin o opțiune standard GNU Autotools pe care trebuie să o cunoașteți: opțiunea--prefix. Acest lucru are legătură cu ierarhia sistemului de fișiere și locul în care va fi instalat software-ul dvs.

Pasul 3: FHS

ierarhia sistemului de fișiere Linux pe o distribuție tipică respectă în mare parte standardul ierarhiei sistemului de fișiere (FHS)

Acest standard explică scopul diferitelor directoare ale sistemului dvs.:/usr/tmp/var și așa mai departe.

când utilizați Autotools GNU— și majoritatea celorlalte sisteme de construire— locația implicită de instalare pentru noul dvs. software va fi/usr/local. Care este o alegere bună, conform FSH ” ierarhia/usr / local este utilizată de administratorul de sistem la instalarea software-ului local? Trebuie să fie sigur de a fi suprascris atunci când software-ul sistemului este actualizat. Poate fi folosit pentru programe și date care pot fi partajate între un grup de gazde, dar care nu se găsesc în /usr.”

/usr/local ierarhia reproduce cumva directorul rădăcină, și veți găsi acolo /usr/local/bin pentru programele executabile, /usr/local/lib pentru biblioteci, /usr/local/share pentru fișierele independente de arhitectură și fișiere așa mai departe.

singura problemă atunci când se utilizează/usr/local copac pentru instalarea software-ului personalizat este fișierele pentru toate software-ul va fi amestecat acolo. Mai ales, după ce ați instalat câteva programe software, va fi greu să urmăriți exact fișierul /usr/local/bin și /usr/local/lib aparține software-ului. Acest lucru nu va cauza nicio problemă sistemului. La urma urmei, /usr/bin este cam aceeași mizerie. Dar asta va deveni o problemă în ziua în care veți dori să eliminați un software instalat manual.

pentru a rezolva această problemă, prefer de obicei instalarea software-ului personalizat în/opt sub-copac în loc. Încă o dată, pentru a cita FHS:

_” / opt este rezervat pentru instalarea de pachete software de aplicații suplimentare.

un pachet care urmează să fie instalat în /opt trebuie să localizeze fișierele sale statice într-un separat/opt/<pachet> sau/opt/<furnizor> arbore de directoare, unde<pachet> este un nume care descrie pachetul software și<furnizor> este numele înregistrat lanana al furnizorului.”_

deci, vom crea un sub-director de /opt special pentru instalarea noastră NodeJS personalizate. Și dacă într-o zi vreau să elimin acel software, va trebui pur și simplu să elimin acel director:

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.

orice altceva decât „ok” după ce comanda make s-a finalizat ar însemna că a existat o eroare în timpul procesului de construire. Pe măsură ce am rulat o construcție paralelă din cauza opțiunii -j, nu este întotdeauna ușor să preluați mesajul de eroare, având în vedere volumul mare de ieșire produs de sistemul de construire.

în cazul unei probleme, trebuie doar să repornițimake, dar fără opțiunea-j de data aceasta. Și eroarea ar trebui să apară aproape de sfârșitul ieșirii:

sh$ make

În cele din urmă, odată ce compilația a ajuns la final, puteți instala software-ul în locația sa executând comanda:

sh$ sudo make install

și testați-l:

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

B. ce se întâmplă dacă lucrurile merg prost în timp ce instalați din codul sursă?

ceea ce am explicat mai sus este în mare parte ceea ce puteți vedea pe pagina „Instrucțiuni de construire” a unui proiect bine documentat. Dar având în vedere acest obiectiv articol este de a vă permite să compilați primul software din surse, ar putea merita să luați timp pentru a investiga unele probleme comune. Deci, voi face din nou întreaga procedură, dar de data aceasta dintr-un sistem Debian 9.0 și CentOS 7.0 proaspăt și minim, astfel încât să puteți vedea erorile pe care le-am întâlnit și cum le-am rezolvat.

From Debian 9.0 „Stretch”

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

această problemă este destul de ușor de diagnosticat și rezolvat. Trebuie doar să instalați git pachet:

:~$ 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

nici o problemă aici.

:~/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.

evident, pentru a compila un proiect, aveți nevoie de un compilator. NodeJS fiind scrise folosind limbajul C++, avem nevoie de un compilator C++. Aici voi instala` g++’, compilatorul GNU C++ în acest scop:

:~/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 alt instrument lipsă. Aceleași simptome. Aceeași soluție:

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

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

succes!

vă rugăm să observați: Am instalat diferitele instrumente unul câte unul pentru a arăta cum să diagnostic problemele de compilare și pentru a vă arăta soluția tipică pentru a rezolva aceste probleme. Dar dacă căutați mai multe informații despre subiect sau citiți alte tutoriale, veți descoperi că majoritatea distribuțiilor au „meta-pachete” care acționează ca o umbrelă pentru a instala unele sau toate instrumentele tipice utilizate pentru compilarea unui software. Pe sistemele bazate pe Debian, veți întâlni probabil pachetul build-essentials în acest scop. Și pe distribuțiile bazate pe Red-Hat, acesta va fi grupul” Instrumente de dezvoltare”.

din CentOS 7.0

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

comanda nu a fost găsită? Doar instalați-l folosind yum manager de pachete:

 ~]$ 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.

ați ghicit: NodeJS este scris folosind limbajul C++, dar sistemul meu nu are compilatorul corespunzător. Yum la salvare. Deoarece nu sunt un utilizator CentOS obișnuit, a trebuit să caut pe Internet numele exact al pachetului care conține compilatorul g++. Mă conduce la acea pagină: 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

succes. Din nou.

C. modificarea software-ului instalat din codul sursă

puteți instala software-ul de la sursă deoarece aveți nevoie de o versiune foarte specifică care nu este disponibilă în depozitul dvs. de distribuție sau pentru că doriți să modificați programul pentru a remedia o eroare sau pentru a adăuga o caracteristică. La urma urmei, open-source este vorba de a face modificări. Așadar, voi profita de această ocazie pentru a vă oferi un gust al puterii pe care o aveți la îndemână acum că sunteți capabil să vă compilați propriul software.

aici, vom face o modificare minoră a surselor de NodeJS. Și vom vedea dacă schimbarea noastră va fi încorporată în versiunea compilată a software-ului:

deschideți fișierul node/src/node.cc în editorul de text preferat (vim, nano, gedit, … ). Și încercați să localizați acel fragment de cod:

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

este în jurul liniei 3830 a fișierului. Apoi modificați linia care conține printf pentru a se potrivi cu aceasta în schimb:

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

apoi întoarceți-vă la terminal. Înainte de a merge mai departe— și pentru a vă oferi mai multe informații despre puterea din spatele git— puteți verifica dacă ați modificat fișierul potrivit:

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

ar trebui să vedeți un „-” (semn minus) înainte de linie așa cum a fost înainte de a o schimba. Și un ” + ” (semn plus) înainte de linie după modificările dvs.

acum este timpul să recompilați și să reinstalați software-ul:

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

de data aceasta, singurul motiv pentru care ar putea eșua este că ați făcut o greșeală de scriere în timp ce schimbați codul. Dacă acesta este cazul, redeschideți fișierul node/src/node.cc din editorul de text și remediați greșeala.

odată ce ați reușit să compilați și să instalați acea nouă versiune NodeJS modificată, veți putea verifica dacă modificările dvs. au fost efectiv încorporate în software:

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

Felicitări! Ați făcut prima schimbare la un program open-source!

D. lăsați shell-ul să localizeze software-ul nostru personalizat de construire

este posibil să fi observat că am lansat întotdeauna software-ul meu NodeJS nou compilat specificând calea absolută către fișierul binar.

/opt/node/bin/node

funcționează. Dar acest lucru este enervant, cel puțin. Există de fapt două modalități comune de a remedia acest lucru.

există de fapt două moduri comune de a stabili problema enervant de a specifica calea absolută a fișierelor binare,
dar pentru a le înțelege trebuie să știți mai întâi că shell-ul localizează fișierele executabile de căutarea pentru ei numai în directoarele specificate de variabila de mediu PATH.

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

aici, pe acel sistem Debian, dacă nu specificați Explicit niciun director ca parte a unui nume de comandă, shell-ul va căuta mai întâi programele executabile în /usr/local/bin, apoi dacă nu se găsește în /usr/bin, atunci dacă nu se găsește în /bin atunci dacă nu se găsește în /usr/local/games atunci dacă nu se găsește în /usr/games, atunci dacă nu se găsește … shell-ul va raporta o eroare „comanda nu a fost găsită”.

având în vedere că, avem două mod de a face o comandă accesibilă shell: adăugându-l la unul dintre directoarele PATH deja configurate. Sau prin adăugarea directorului care conține fișierul nostru executabil la PATH.

adăugarea unui link de la /usr/local/bin

doar copierea executabil binar nod de la /opt/node/bin la /usr/local/bin ar fi o idee proastă, deoarece de a face acest lucru, programul executabil nu ar mai fi capabil de a localiza celelalte componente necesare aparținând /opt/node/ (este o practică comună pentru software-ul pentru a localiza fișierele sale de resurse în raport cu propria locație).

deci, modul tradițional de a face acest lucru este folosind o legătură simbolică:

:~/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)

aceasta este o soluție simplă și eficientă, mai ales dacă un pachet software este format din doar câteva programe executabile bine cunoscute— deoarece trebuie să creați o legătură simbolică pentru fiecare comandă invokabilă de utilizator. De exemplu, dacă sunteți familiarizat cu NodeJS, știți npm aplicație însoțitoare ar trebui să fac legătura simbolică de la /usr/local/bin de asemenea. Dar am lăsat asta ca un exercițiu.

modificarea căii

În primul rând, dacă ați încercat soluția precedentă, eliminați link-ul simbolic nod creat anterior pentru a porni de la o stare clară:

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

și acum, aici este comanda magic pentru a schimba 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

pur și simplu a spus, Am înlocuit conținutul PATH variabila de mediu de conținutul său anterior, dar prefixat de /opt/node/bin. Deci, după cum vă puteți imagina acum, shell-ul va privi mai întâi în directorul /opt/node/bin pentru programe executabile. Putem confirma că folosind which comanda:

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

în timp ce soluția „link” este permanentă de îndată ce ați creat legătura simbolică în /usr/local/binPATH este eficient numai în shell-ul curent. Vă voi lăsa să faceți câteva cercetări despre cum să faceți modificări în PATH permanenți. Ca indiciu, are legătură cu „profilul”tău. Dacă găsiți soluția, nu ezitați să împărtășiți acest lucru cu ceilalți cititori folosind secțiunea de comentarii de mai jos!

E. Cum să eliminați software-ul nou instalat din codul sursă

deoarece software-ul nostru NodeJS compilat personalizat se află complet în directorul /opt/node-v8.1.1, eliminarea acelui software nu necesită mai mult efort decât utilizarea comenzii rm pentru a elimina acel director:

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

atenție: sudo și rm -rf Sunt un cocktail periculos! Verificați întotdeauna comanda de două ori înainte de a apăsa tasta „enter”. Nu veți avea nici un mesaj de confirmare și nici un undelete dacă eliminați directorul greșit …

apoi, dacă ați modificatPATH, va trebui să reveniți la aceste modificări, ceea ce nu este deloc complicat.

și dacă ați creat link-uri de la /usr/local/bin va trebui să le eliminați pe toate:

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

așteptați? Unde a fost iadul dependenței?

ca un comentariu final, dacă ați citit despre compilarea propriul software personalizat, este posibil să fi auzit despre iad dependență. Aceasta este o poreclă pentru acea situație enervantă în care, înainte de a putea compila cu succes un software, trebuie mai întâi să compilați o bibliotecă prealabilă, care la rândul său necesită o altă bibliotecă care ar putea fi la rândul său incompatibilă cu un alt software pe care l-ați instalat deja.

o parte din sarcina administratorilor de pachete din distribuția dvs. este de a rezolva de fapt iadul de dependență și de a vă asigura că diferitele programe software ale sistemului dvs. utilizează biblioteci compatibile și sunt instalate în ordinea corectă.

pentru acest articol, am ales, intenționat, să instalez NodeJS, deoarece practic nu are dependențe. Am spus „practic” pentru că, de fapt, are dependențe. Dar codul sursă al acestor dependențe este prezent în depozitul sursă al proiectului (în subdirectorul node/deps), deci nu trebuie să le descărcați și să le instalați manual înainte de mână.