rövid: ez a részletes útmutató elmagyarázza, hogyan kell telepíteni a szoftvert a forráskódból a program telepítése a forráskódból Linuxban, valamint a telepített szoftver eltávolítása a forráskódból.
a Linux disztribúció egyik legnagyobb erőssége a csomagkezelő és a hozzá tartozó szoftvertár. Velük, akkor minden szükséges eszközt, erőforrást, hogy töltse le, majd telepítse az új szoftvert a számítógépre egy teljesen automatizált módon.
de minden erőfeszítésük ellenére a csomag karbantartói nem tudnak minden egyes felhasználási esetet kezelni. Azt sem tudják csomagolni az összes rendelkezésre álló szoftver odakinn. Tehát még mindig vannak olyan helyzetek,amikor új szoftvert kell összeállítania és telepítenie. Ami engem illet, a leggyakoribb ok, messze, össze kell állítanom néhány szoftvert, amikor egy nagyon specifikus verziót kell futtatnom, vagy módosítani kell a forráskódot néhány divatos összeállítási lehetőség használatával.
Ha az Ön igényei az utóbbi kategóriába tartoznak, valószínű, hogy már tudja, mit kell tennie. De a Linux-felhasználók túlnyomó többsége számára a forráskódból történő szoftver összeállítása és telepítése először úgy néz ki, mint egy beavatási szertartás: kissé ijesztő; de azzal az ígérettel, hogy belép a lehetőségek új világába és egy kiváltságos közösség presztízsének helyére.
- A. szoftver telepítése a forráskódból Linuxban
- 1. lépés: a forráskód megszerzése a GitHub-tól
- 2. Lépés: a Megértés, a Build Rendszer a program
- 3. lépés: Az FHS
- A Debian 9.0 “Stretch”
- a CentOS 7.0
- C. a forráskódból telepített szoftver módosítása
- D. hagyja, hogy a shell keresse meg az egyéni build szoftvert
- Hozzá egy link a /usr/local/bin
- Módosítása a PATH
- E. Hogyan lehet eltávolítani az újonnan telepített szoftvert a
- várj? Hol volt a függőségi pokol?
A. szoftver telepítése a forráskódból Linuxban
és pontosan ezt fogjuk tenni itt. E cikk alkalmazásában tegyük fel, hogy telepítenem kell a NodeJS 8.1.1-et a rendszeremre. Ez a verzió pontosan. Egy verzió, amely nem érhető el a Debian adattár:
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
most, telepítése NodeJs Ubuntu vagy Debian elég egyszerű, ha ezt a csomagkezelő. De csináljuk a forráskódon keresztül.
1. lépés: a forráskód megszerzése a GitHub-tól
mint sok nyílt forráskódú projekt, a NodeJS forrásai megtalálhatók a GitHub – on: https://github.com/nodejs/node
tehát menjünk közvetlenül oda.
Ha nem ismeri a GitHub, a git vagy bármely más verziókezelő rendszert, amelyet érdemes megemlíteni, a tároló tartalmazza a szoftver aktuális forrását, valamint a szoftver előzményeit minden módosítás az évek során, hogy a szoftver. Végül egészen a legelső Sort írt, hogy a projekt. A fejlesztők számára ennek a történelemnek a megtartása számos előnnyel jár. Számunkra ma a legfontosabb az, hogy képesek leszünk megszerezni a projekt forrásait, ahogyan az adott időpontban voltak. Pontosabban, én képes lesz arra, hogy a források, mint voltak, amikor a 8.1.1 változat akarok megjelent. Még akkor is, ha azóta sok módosítás történt.
a Githubon a” branch ” gomb segítségével navigálhat a szoftver különböző verziói között. A “Branch” és a “tags” némiképp rokon fogalmak a Git-ben. Alapvetően, a fejlesztők létre “branch”, “címkék”, hogy nyomon kövesse a fontos események a projekt történetében, mint amikor elkezd dolgozni egy új funkció, vagy amikor közzétesz egy kiadás. Nem megyek be a részletekbe itt, csak annyit kell tudnod, hogy a “V8.1.1”
miután kiválasztotta a “V8.1.1 ” címke, az oldal frissül, a legnyilvánvalóbb változás, hogy a címke most az URL részeként jelenik meg. Ezenkívül észre fogja venni, hogy a fájl módosításának dátuma is eltérő. A most látott forrásfa az, amely a v8.1.1 címke létrehozásakor létezett. Bizonyos értelemben egy olyan verzióvezérlő eszközre gondolhat, mint a git, mint egy időutazó gép, amely lehetővé teszi, hogy oda-vissza menjen a projekt történetébe.
Ezen a ponton letölthetjük a nodejs 8.1.1. Nem hagyhatja ki a nagy kék gombot, amely azt javasolja, hogy töltse le a projekt ZIP archívumát. Ami engem illet, a magyarázat kedvéért letöltöm és kibontom a ZIP-et a parancssorból. De ha inkább egy GUI eszközt szeretne használni, ne habozzon ezt megtenni:
wget https://github.com/nodejs/node/archive/v8.1.1.zipunzip v8.1.1.zipcd node-8.1.1/
a ZIP archívum letöltése nagyszerűen működik. De ha azt szeretné, hogy “mint egy profi”, azt javaslom, hogy használja közvetlenül a git
eszközt a források letöltéséhez. Ez egyáltalán nem bonyolult-és ez egy szép első kapcsolatfelvétel lesz egy olyan eszközzel, amellyel gyakran találkozik:
# 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/
egyébként, ha problémája van, csak vegye figyelembe a cikk első részét általános bevezetésnek. Később részletesebb magyarázataim vannak a Debian – és RedHat-alapú disztribúciókról, hogy segíthessek a gyakori problémák elhárításában.
Mindenesetre, amikor letöltöttem a forrást, a git
vagy, mint egy ZIP archívum, most kell, hogy pontosan ugyanaz a forrás fájlok az aktuális könyvtárban:
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
2. Lépés: a Megértés, a Build Rendszer a program
szoktunk beszélni “összeállítása a forrásból” de az összeállítás csak az egyik fázis, köteles egy működő szoftver forrását. A build rendszer egy sor eszköz és gyakorlat használják automatizálni és megfogalmazni ezeket a különböző feladatokat annak érdekében, hogy építsenek teljes egészében a szoftver csak néhány parancs kiadásával.
Ha a koncepció egyszerű, a valóság kissé bonyolultabb. Mivel a különböző projektek vagy programozási nyelv eltérő követelményeket támaszthat. Vagy a programozó ízlése miatt. Vagy a támogatott platformok. Vagy történelmi okokból. Vagy … vagy.. van egy szinte végtelen lista az okok közül, hogy válasszon vagy hozzon létre egy másik build rendszer. Mindez azt jelenti, hogy sok különböző megoldás létezik.
a NodeJS GNU-stílusú build rendszert használ, népszerű választás a nyílt forráskódú közösségben, és ismét jó módja az utazás megkezdésének.
a build rendszer írása és hangolása meglehetősen összetett feladat, de a “végfelhasználó” számára a GNU-stílusú build rendszerek két eszközzel könnyítik meg a feladatot: configure
és make
.
a configure
fájl egy projektspecifikus szkript, amely ellenőrzi a célrendszer konfigurációját és a rendelkezésre álló funkciót annak érdekében, hogy a projekt felépíthető legyen, végül a jelenlegi platform sajátosságaival foglalkozik.
egy tipikusconfigure
fontos része aMakefile
. Ez az a fájl, amely tartalmazza a projekt hatékony felépítéséhez szükséges utasításokat.
a make
eszköz, másrészt, egy POSIX eszköz elérhető bármely Unix-szerű rendszer. Elolvassa a projektspecifikus Makefile
és elvégzi a szükséges műveleteket a program létrehozásához és telepítéséhez.
de, mint mindig a Linux világában, még mindig van némi engedékenység az építmény testreszabásában az Ön egyedi igényeihez.
./configure --help
a configure -help
parancs megmutatja az összes rendelkezésre álló konfigurációs lehetőséget. Ez ismét nagyon projektspecifikus. Őszintén szólva, néha szükség van a projektbe ásni, mielőtt teljesen megértené az egyes konfigurálási lehetőségek jelentését.
de van legalább egy szabványos GNU Autotools opció, amelyet tudnia kell: a --prefix
opció. Ennek köze van a fájlrendszer hierarchiájához és a szoftver telepítésének helyéhez.
3. lépés: Az FHS
a Linux fájlrendszer hierarchiája egy tipikus disztribúcióban többnyire megfelel a fájlrendszer hierarchiájának (FHS)
Ez a szabvány magyarázza a rendszer különböző könyvtárainak célját: /usr
/tmp
/var
stb.
a GNU Autotools— és a legtöbb más build rendszer-használatakor az új szoftver alapértelmezett telepítési helye /usr/local
. Melyik a jó választás, mivel az FSH szerint “a / usr / helyi hierarchiát a rendszergazda használja a szoftver helyi telepítésekor? A rendszerszoftver frissítésekor biztonságosnak kell lennie a felülírástól. Lehet használni a programok és adatok, amelyek megoszthatók között egy csoport házigazdák, de nem található /usr.”
A /usr/local
hierarchia valahogy ismétlések a gyökér könyvtárban, majd ott /usr/local/bin
a végrehajtható programok, /usr/local/lib
a könyvtárak, /usr/local/share
az architektúra-független fájlokat stb.
az egyetlen probléma, ha a/usr/local
fa egyéni szoftver telepítése a fájlokat az összes szoftver összekeverjük ott. Különösen, miután telepített egy pár szoftvert, nehéz lesz nyomon követni, hogy melyik fájl pontosan a /usr/local/bin
és /usr/local/lib
melyik szoftverhez tartozik. Ez azonban nem okoz problémát a rendszernek. Végül is, /usr/bin
éppen ugyanolyan rendetlenség. De ez lesz a kérdés a nap, amikor el akarja távolítani a manuálisan telepített szoftvert.
a probléma megoldásához általában inkább az egyéni szoftvert telepítem a /opt
alfába. Még egyszer, idézni az FHS-t:
_ ” / opt van fenntartva a telepítés kiegészítő alkalmazás szoftver csomagok.
a /opt-be telepítendő csomag statikus fájljait külön /opt/<csomag> vagy /opt/<szolgáltató> könyvtárfa, ahol <csomag> a szoftvercsomagot leíró név és <szolgáltató> a szolgáltató lanana bejegyzett neve.”_
így létrehozunk egy alkönyvtárat a /opt
kifejezetten az egyéni NodeJS telepítéshez. Ha egyszer el akarom távolítani ezt a szoftvert, akkor egyszerűen el kell távolítanom ezt a könyvtárat:
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.
bármi, de az “ok” a make
parancs befejezése után azt jelenti, hogy hiba történt az építési folyamat során. Mivel a -j
opció miatt párhuzamosan futottunk, nem mindig könnyű letölteni a hibaüzenetet, tekintettel a build rendszer által előállított nagy mennyiségű kimenetre.
probléma esetén indítsa újra a make
– t, de ezúttal a -j
opció nélkül. A hibának a kimenet vége közelében kell megjelennie:
sh$ make
végül, miután az összeállítás véget ért, telepítheti a szoftvert a helyére a következő parancs futtatásával:
sh$ sudo make install
és tesztelje:
sh$ /opt/node/bin/node --versionv8.1.1
H2 > B. mi van, ha a dolgok rosszul mennek a forráskód telepítése közben?
amit fentebb kifejtettem, többnyire az, amit egy jól dokumentált projekt “build instruction” oldalán láthat. De mivel ez a cikk célja, hogy lehetővé teszi, hogy fordítja az első szoftver forrásokból, érdemes időt arra, hogy vizsgálja meg néhány gyakori probléma. Szóval, újra végigcsinálom az egész eljárást, de ezúttal egy friss és minimális Debian 9.0 és CentOS 7.0 rendszerből, így láthatod a hibákat, amelyekkel találkoztam, és hogyan oldottam meg őket.
A Debian 9.0 “Stretch”
:~$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node-bash: git: command not found
Ez a probléma meglehetősen könnyen diagnosztizálható és megoldható. Csak telepítse agit
csomagot:
:~$ 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
nincs probléma itt.
:~/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.
nyilvánvaló, hogy egy projekt összeállításához fordítóra van szüksége. NodeJS a C++ nyelv használatával íródott, szükségünk van egy C++ fordítóra. Itt telepítem a”G++” – t, a GNU C++ fordítót erre a célra:
:~/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
egy másik hiányzó eszköz. Ugyanazok a tünetek. Ugyanaz a megoldás:
:~/node$ sudo apt-get install make:~/node$ make -j9 && echo okok
:~/node$ sudo make install:~/node$ /opt/node/bin/node --versionv8.1.1
siker!
kérjük, vegye figyelembe: Telepítettem a különböző eszközöket egyenként, hogy megmutassam, hogyan kell diagnosztizálni az összeállítási problémákat, valamint hogy megmutassam a tipikus megoldást ezeknek a problémáknak a megoldására. De ha további információt keres a témáról, vagy más oktatóanyagokat olvas, akkor rájössz, hogy a legtöbb disztribúciónak “meta-csomagjai” vannak, amelyek esernyőként működnek a szoftver összeállításához használt néhány vagy az összes tipikus eszköz telepítéséhez. A Debian alapú rendszereken valószínűleg a build-essentials csomaggal találkozol erre a célra. A Red-Hat alapú disztribúciókon pedig ez lesz a” fejlesztési eszközök ” csoport.
a CentOS 7.0
~]$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node-bash: git: command not found
parancs nem található? Csak telepítse a yum
csomagkezelő:
~]$ 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.
kitalálod: a nodejs a C++ nyelv használatával van írva, de a rendszeremben hiányzik a megfelelő fordító. Yum a mentő. Mivel nem vagyok rendszeres CentOS felhasználó, valójában az interneten kellett keresnem a G++ fordítót tartalmazó csomag pontos nevét. Vezető nekem, hogy az oldal: 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
siker. Még.
C. a forráskódból telepített szoftver módosítása
telepítheti a szoftvert a forrásból, mert nagyon specifikus verzióra van szüksége, amely nem érhető el a terjesztési tárolóban, vagy azért, mert módosítani szeretné a programot egy hiba kijavításához vagy egy szolgáltatás hozzáadásához. Végtére is, a nyílt forráskódú a módosítások elvégzéséről szól. Tehát megragadom ezt a lehetőséget, hogy megkóstolhassam a rendelkezésre álló erőt, most, hogy összeállíthatja saját szoftverét.
itt kisebb változást fogunk végrehajtani a NodeJS forrásaiban. Látni fogjuk, hogy a változásunk beépül-e a szoftver lefordított verziójába:
nyissa meg a fájlt node/src/node.cc
kedvenc szövegszerkesztőjében (vim, nano, gedit,…). Próbálja meg megtalálni a kódrészletet:
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); }
Ez a fájl 3830 sorában található. Ezután módosítsa a printf
sort, hogy megfeleljen ennek:
printf("%s (compiled by myself)\n", NODE_VERSION);
majd térjen vissza a terminálhoz. Mielőtt továbbmenne— és hogy még több betekintést nyújtson a git mögötti energiába-ellenőrizheti, hogy módosította-e a megfelelő fájlt:
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();
a sor előtt látnia kell egy ” – ” (mínusz jel), mint mielőtt megváltoztatta volna. És egy ” + ” (plusz jel) a sor előtt a módosítások után.
itt az ideje a szoftver újrakompilálásának és újratelepítésének:
make -j9 && sudo make install && echo okok
Ez alkalommal az egyetlen ok, amiért nem sikerül, az az, hogy elírtál egy elírást a kód megváltoztatása közben. Ebben az esetben nyissa meg újra a node/src/node.cc
fájlt a szövegszerkesztőben, majd javítsa ki a hibát.
miután sikerült összeállítania és telepítenie az új módosított NodeJS verziót, ellenőrizheti, hogy a módosításokat ténylegesen beépítették-e a szoftverbe:
:~/node$ /opt/node/bin/node --versionv8.1.1 (compiled by myself)
Gratulálunk! Már megtette az első változás, hogy egy nyílt forráskódú program!
D. hagyja, hogy a shell keresse meg az egyéni build szoftvert
lehet, hogy észrevette, hogy mindig elindítottam az újonnan összeállított NodeJS szoftvert a bináris fájl abszolút elérési útjának megadásával.
/opt/node/bin/node
működik. De ez bosszantó, hogy mondjuk a legkevésbé. Valójában két közös módja van ennek rögzítésére.
valójában két közös módja van a bináris fájlok abszolút elérési útjának meghatározásának bosszantó problémájának rögzítésére,
de ahhoz, hogy megértsük őket, először tudnia kell, hogy a shell a futtatható fájlokat csak a PATH environment változó által megadott könyvtárakban keresi.
:~/node$ echo $PATH/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
itt, ezen a Debian rendszeren, ha nem ad meg kifejezetten semmilyen könyvtárat egy parancsnév részeként, a shell először a /usr/local/bin
futtatható programokat fogja keresni, akkor ha nem található a /usr/bin
, akkor ha nem található a /bin
akkor, ha nem található a /usr/local/games
, akkor ha nem található a /usr/games
, akkor ha nem található … a shell hibát jelent “command not found”.
tekintettel arra, hogy van két módja annak, hogy egy parancs hozzáférhető a shell: ha hozzáadja a már konfigurált PATH
könyvtárak egyikéhez. Vagy a futtatható fájlt tartalmazó könyvtár hozzáadásával a PATH
– hoz.
Hozzá egy link a /usr/local/bin
másolás a csomópont bináris futtatható a /opt/node/bin
, hogy a /usr/local/bin
lenne egy rossz ötlet, mivel ezzel a futtatható program már nem lenne képes megtalálni az egyéb szükséges alkatrészek tartozó /opt/node/
(ez egy bevett gyakorlat, hogy a szoftver, hogy keresse meg a forrás fájlok relatív, hogy saját helyét).
tehát ennek hagyományos módja egy szimbolikus link használata:
:~/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)
Ez egy egyszerű és hatékony megoldás, különösen akkor, ha egy szoftvercsomag csak néhány jól ismert futtatható programból készül— mivel szimbolikus linket kell létrehoznia minden egyes felhasználó számára-invokable parancs. Például, ha ismeri a NodeJS-t, akkor ismeri a npm
companion alkalmazást, amelyet a /usr/local/bin
– tól kell symlink-nek is. De hagytam, hogy ez a gyakorlat.
Módosítása a PATH
Először is, ha a megelőző megoldás, távolítsa el a csomópont szimbolikus linket korábban létrehozott először egy tiszta állapotban:
:~/node$ sudo rm /usr/local/bin/node:~/node$ which -a node || echo not foundnot found
most, hogy itt, a mágikus parancs, hogy változtassa meg a 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
csak azt mondtam, én a helyébe a tartalom a PATH
környezeti változó által a korábbi tartalmat, de előtaggal /opt/node/bin
. Tehát, ahogy most el tudod képzelni, a héj először a/opt/node/bin
könyvtárba néz a végrehajtható programokhoz. Megerősíthetjük, hogy a which
parancs használatával:
:~/node$ which -a node || echo not found/opt/node/bin/node:~/node$ node --versionv8.1.1 (compiled by myself)
mivel a “link” megoldás állandó, amint létrehozta a szimbolikus linket a /usr/local/bin
, a PATH
változás csak az aktuális héjba hat. Hagyom, hogy végezzen néhány kutatást arról, hogyan lehet megváltoztatni a PATH
állandókat. Tippként köze van a “profilodhoz”. Ha megtalálja a megoldást, ne habozzon megosztani ezt a többi olvasóval az alábbi megjegyzés szakasz segítségével!
E. Hogyan lehet eltávolítani az újonnan telepített szoftvert a
forráskódból, mivel az egyéni összeállított NodeJS szoftver teljesen a /opt/node-v8.1.1
könyvtárban található, a szoftver eltávolítása nem igényel több erőfeszítést, mint az rm parancs használata a könyvtár eltávolításához:
sudo rm -rf /opt/node-v8.1.1
Óvakodj: sudo
a DIV>és rm -rf
veszélyes koktél! Az “enter” gomb megnyomása előtt mindig ellenőrizze a parancsot kétszer. Ha rossz könyvtárat távolít el…
, akkor, ha módosította a PATH
, vissza kell állítania ezeket a változtatásokat, ami egyáltalán nem bonyolult.
és ha a/usr/local/bin
hivatkozásokat hoztál létre, akkor mindet el kell távolítanod:
:~/node$ sudo find /usr/local/bin \ -type l \ -ilname "/opt/node/*" \ -print -delete/usr/local/bin/node
várj? Hol volt a függőségi pokol?
végső megjegyzésként, ha elolvassa a saját egyéni szoftver összeállítását, akkor talán hallott a függőség pokoláról. Ez egy becenév arra a bosszantó helyzetre, amikor mielőtt sikeresen lefordítana egy szoftvert, először össze kell állítania egy előfeltételes könyvtárat, amely viszont egy másik könyvtárat igényel, amely viszont összeegyeztethetetlen lehet a már telepített más szoftverekkel.
a disztribúció csomag karbantartóinak feladata az, hogy ténylegesen megoldják ezt a függőségi Pokolot, és biztosítsák, hogy a rendszer különböző szoftverei kompatibilis könyvtárakat használjanak, és a megfelelő sorrendben vannak telepítve.
ehhez a cikkhez szándékosan a NodeJS telepítését választottam, mivel gyakorlatilag nincs függősége. Azt mondtam “gyakorlatilag”, mert valójában függőségek vannak. De ezeknek a függőségeknek a forráskódja jelen van a projekt forrástárában (a node/deps
alkönyvtárban), így nem kell kézzel letölteni és telepíteni őket.