Hogyan telepítsük a szoftvert a forráskódból… és távolítsuk el utána

Hogyan telepítsük a szoftvert a forráskódból

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

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

the nodejs official GitHub repository

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.

válassza ki a V8.1.1 címkét a NodeJS GitHub adattárban

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”

a NodeJS GitHub tároló, mint a V8.1.1 címke létrehozásakor

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.

NodeJS GitHub repository letöltés ZIP gombként

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.

Related Posts

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük