lyhyt: tämä yksityiskohtainen opas selittää, miten ohjelman asentaminen lähdekoodista Linuxiin ja asennetun ohjelmiston poistaminen lähdekoodista.

yksi Linux-jakelusi suurimmista vahvuuksista on sen paketinhallinta ja siihen liittyvä ohjelmistovarasto. Niiden avulla sinulla on kaikki tarvittavat työkalut ja resurssit ladata ja asentaa uusia ohjelmistoja tietokoneellesi täysin automatisoidusti.

mutta kaikista ponnisteluistaan huolimatta paketin ylläpitäjät eivät pysty hoitamaan jokaista käyttötapausta. He eivät myöskään voi paketoida kaikkia saatavilla olevia ohjelmistoja. Joten on vielä tilanteita, joissa sinun täytyy koota ja asentaa uusia ohjelmistoja itse. Mitä minuun tulee, yleisin syy, ylivoimaisesti, minun täytyy kääntää joitakin ohjelmistoja on, kun minun täytyy ajaa hyvin erityinen versio, tai muuttaa lähdekoodia käyttämällä joitakin fancy kokoelma vaihtoehtoja.

jos tarpeesi kuuluvat jälkimmäiseen luokkaan, on todennäköistä, että tiedät jo, mitä tehdä. Mutta suurimmalle osalle Linux-käyttäjiä ohjelmistojen kokoaminen ja asentaminen lähdekoodista ensimmäistä kertaa saattaa näyttää aloitusseremonialta: hieman pelottavalta; mutta lupauksella astua uuteen mahdollisuuksien maailmaan ja arvovaltaan etuoikeutetussa yhteisössä.

A. ohjelmiston asentaminen lähdekoodista Linuxiin

ja juuri niin me teemme täällä. Tässä artikkelissa sanotaan, että minun täytyy asentaa NodeJS 8.1.1 järjestelmääni. Juuri se versio. Versio, joka ei ole saatavilla Debianin arkistosta:

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

nyt nodejs: n asentaminen Ubuntuun tai Debianiin on melko yksinkertaista, jos sen tekee paketinhallinnan avulla. Mutta tehdään se lähdekoodin kautta.

Vaihe 1: lähdekoodin saaminen GitHubista

monien avoimen lähdekoodin projektien tapaan NodeJS: n lähteet löytyvät GitHubista: https://github.com/nodejs/node

joten, mennään suoraan sinne.

Jos et tunne GitHubia, gitiä tai muuta maininnan arvoista versionhallintajärjestelmää, arkistossa on ohjelmiston nykyinen lähde sekä historia kaikki muutokset, joita ohjelmistoon on tehty vuosien varrella. Lopulta jopa aivan ensimmäinen rivi kirjoitettu, että projekti. Kehittäjille, pitää että historia on monia etuja. Meille tänään, tärkein on, että voimme saada lähteet hankkeen kuin ne olivat tiettynä ajankohtana. Tarkemmin, voin saada lähteet kuin ne olivat, kun 8.1.1 versio Haluan julkaistiin. Vaikka sen jälkeen on tehty paljon muutoksia.

GitHubissa voit siirtyä ”haara” – painikkeella ohjelmiston eri versioiden välillä. ”Branch” ja ”tags” ovat jonkin verran toisiinsa liittyviä käsitteitä Git: ssä. Periaatteessa kehittäjät luovat ”haaran” ja ”tagit” pitääkseen kirjaa projektin historian tärkeistä tapahtumista, kuten kun he alkavat työstää uutta ominaisuutta tai kun he julkaisevat julkaisun. En mene yksityiskohtiin tässä, kaikki mitä sinun tarvitsee tietää on etsin versiota tagged ”v8.1.1”

valittuaan ”V8.1.1 ” tag, Sivu on päivitetty, ilmeisin muutos on tag näkyy nyt osana URL. Lisäksi, huomaat tiedoston muutos päivämäärä ovat erilaisia liian. Lähdepuu, jonka nyt näet, on se, joka oli olemassa tunnisteen V8.1. 1 luomisen aikaan. Jossain mielessä Gitin kaltaista versionhallintatyökalua voi ajatella aikamatkakoneena, jonka avulla voi mennä edestakaisin projektihistoriaan.

tässä vaiheessa voimme ladata nodejs 8.1.1: n lähteet. Et voi olla huomaamatta iso sininen painike ehdottaa ladata ZIP arkisto projektin. Mitä minuun tulee, lataan ja poistan ZIP komentoriviltä selityksen vuoksi. Mutta jos käytät mieluummin GUI-työkalua, älä epäröi tehdä sitä sen sijaan:

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

ZIP-arkiston lataaminen toimii loistavasti. Mutta jos haluat tehdä sen ”kuin ammattilainen”, suosittelen käyttämään suoraan git – työkalua lähteiden lataamiseen. Se ei ole lainkaan monimutkainen— ja se on mukava ensikosketus työkaluun, johon törmäät usein:

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

muuten, jos sinulla on ongelma, harkitse tämän artikkelin ensimmäistä osaa yleisenä johdantona. Myöhemmin minulla on yksityiskohtaisempia selityksiä Debian-ja RedHat-pohjaisille jakeluille auttaakseni sinua vianmäärityksessä.

joka tapauksessa, aina kun latasit lähteen käyttäen git tai ZIP-arkistona, sinulla pitäisi nyt olla täsmälleen samat lähdekooditiedostot nykyisessä hakemistossa:

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

Vaihe 2: ohjelman rakennusjärjestelmän ymmärtäminen

puhumme yleensä ”lähteiden kokoamisesta”, mutta koostaminen on vain yksi vaiheista tarvitaan tuottamaan toimiva ohjelmisto sen lähteestä. Build-järjestelmä on joukko työkaluja ja käytäntöjä, joita käytetään automatisoimaan ja ilmaisemaan nämä eri tehtävät, jotta voidaan rakentaa kokonaan ohjelmisto vain antamalla muutamia komentoja.

Jos käsite on yksinkertainen, todellisuus on hieman monimutkaisempi. Koska eri projekteilla tai ohjelmointikielellä voi olla erilaisia vaatimuksia. Tai ohjelmoijan maun takia. Tai tuetut alustat. Tai historiallisesta syystä. Tai … tai.. on lähes loputon lista syitä valita tai luoda toinen rakentaa järjestelmä. Kaikki tämä sanoa on olemassa monia erilaisia ratkaisuja käytetään siellä.

NodeJS käyttää GNU-tyylistä rakentamisjärjestelmää, se on suosittu valinta avoimen lähdekoodin yhteisössä ja jälleen kerran hyvä tapa aloittaa matkasi.

rakentamisjärjestelmän kirjoittaminen ja virittäminen on melko monimutkainen tehtävä, mutta ”loppukäyttäjälle” GNU-tyyliset rakentamisjärjestelmät helpottavat tehtävää kahdella työkalulla: configure ja make.

configure tiedosto on projektikohtainen skripti, joka tarkistaa kohdejärjestelmän kokoonpanon ja käytettävissä olevan ominaisuuden varmistaakseen, että projekti voidaan rakentaa, ja lopulta käsittelee nykyisen alustan erityispiirteet.

tärkeä osa tyypillistä configure tehtävää on rakentaa Makefile. Tämä on tiedosto, joka sisältää tarvittavat ohjeet projektin tehokkaaseen rakentamiseen.

make työkalu sen sijaan on POSIX-työkalu, joka on saatavilla mihin tahansa Unixin kaltaiseen järjestelmään. Se lukee projektikohtaisen Makefile ja suorittaa ohjelman rakentamiseen ja asentamiseen tarvittavat toiminnot.

mutta, kuten aina Linux-maailmassa, sinulla on vielä jonkin verran lempeyttä muokata rakennetta juuri sinun tarpeisiisi.

./configure --help

configure -help komento näyttää kaikki käytettävissä olevat asetusasetukset. Tämä on jälleen kerran hyvin hankekohtaista. Ja ollakseni rehellinen, se on joskus tarpeen kaivaa projektin ennen täysin ymmärtää merkitys jokaisen määrittää vaihtoehto.

mutta on olemassa ainakin yksi standardi GNU Autotools-vaihtoehto, joka sinun täytyy tietää: --prefix – vaihtoehto. Tämä liittyy tiedostojärjestelmän hierarkiaan ja ohjelmistosi asennuspaikkaan.

Vaihe 3: FHS

tyypillisen jakelun Linux-tiedostojärjestelmän hierarkia noudattaa enimmäkseen tiedostojärjestelmän Hierarkiastandardia (FHS)

, joka standardi selittää järjestelmäsi eri hakemistojen tarkoituksen: /usr/tmp/var ja niin edelleen.

käytettäessä GNU Autotoolsia— ja useimpia muita rakentamisjärjestelmiä— uuden ohjelmiston oletusasennuspaikka on /usr/local. Mikä on hyvä valinta, koska FSH: n mukaan ”/usr/local hierarchy on järjestelmän ylläpitäjän käyttöön asennettaessa ohjelmistoja paikallisesti? Sen on oltava turvassa ylikirjoitukselta, kun järjestelmäohjelmisto päivitetään. Sitä voidaan käyttää ohjelmille ja tiedoille, jotka ovat jaettavissa isäntäryhmän kesken, mutta joita ei löydy /usr: stä.”

/usr/local hierarkia jotenkin replikoi juurihakemiston, ja sieltä löytyy /usr/local/bin suoritettaville ohjelmille, /usr/local/lib kirjastoille, /usr/local/share arkkitehtuurista riippumattomille tiedostoille ja niin päälle.

ainoa ongelma käytettäessä /usr/local puu mukautettujen ohjelmistojen asennukseen on, että kaikkien ohjelmistojesi tiedostot sekoitetaan siellä. Varsinkin parin ohjelmiston asentamisen jälkeen on vaikea seurata, mihin tiedostoon /usr/local/bin ja /usr/local/lib kuuluu mihinkin ohjelmistoon. Se ei aiheuta mitään ongelmia järjestelmän vaikka. Loppujen lopuksi /usr/bin on suunnilleen sama sotku. Mutta se tulee ongelma päivä haluat poistaa manuaalisesti asennettu ohjelmisto.

tuon ongelman ratkaisemiseksi mieluummin asennan mukautetun ohjelmiston /opt alapuuhun sen sijaan. Vielä kerran, lainatakseni FHS: ää:

_” / opt on varattu lisäosasovellusohjelmistopakettien asentamiseen.

/opt-järjestelmään asennettavan Paketin tulee paikantaa staattiset tiedostonsa erilliseen /opt/<paketti> tai /opt/<tarjoaja> hakemistopuu, jossa <package> on nimi, joka kuvaa ohjelmistopakettia ja <provider> on palveluntarjoajan lanana rekisteröity nimi.”_

joten luomme alihakemiston /opt nimenomaan mukautettua NodeJS-asennustamme varten. Ja jos jonain päivänä haluan poistaa kyseisen ohjelmiston, minun on yksinkertaisesti poistettava kyseinen Hakemisto:

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.

kaikki muu paitsi ”ok” sen jälkeen, kun make komento on suoritettu, tarkoittaisi, että rakentamisprosessin aikana olisi tapahtunut virhe. Koska suoritimme rinnakkaisen käännöksen -j – vaihtoehdon vuoksi, virheilmoitusta ei ole aina helppo hakea, kun otetaan huomioon build-järjestelmän tuottama suuri ulostulomäärä.

ongelman sattuessa Käynnistä make, mutta ilman -j – vaihtoehtoa tällä kertaa. Ja virheen pitäisi näkyä tulosteen loppupuolella:

sh$ make

lopuksi, kun kooste on mennyt loppuun, voit asentaa ohjelmistosi sen sijaintiin ajamalla komennon:

sh$ sudo make install

ja testata sen:

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

B. Mitä jos asiat menevät pieleen asennettaessa lähdekoodia?

mitä olen edellä selittänyt, on lähinnä se, mitä näet hyvin dokumentoidun projektin ”build instruction”-sivulla. Mutta koska tämä artikkeli tavoitteena on antaa sinulle koota ensimmäinen ohjelmisto lähteistä, se voi olla syytä ottaa aikaa tutkia joitakin yhteisiä kysymyksiä. Niin, aion tehdä koko menettelyn uudelleen, mutta tällä kertaa tuore ja minimaalinen Debian 9.0 ja CentOS 7.0 järjestelmiä, jotta voit nähdä virheet kohtasin ja miten Ratkaisin ne.

Debian 9.0 ”Stretch”

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

tämä ongelma on melko helppo diagnosoida ja ratkaista. Asenna vain git paketti:

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

ei ongelmaa täällä.

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

ilmeisesti projektin kääntämiseen tarvitaan kääntäjä. Koska NodeJS on kirjoitettu C++ kielellä, tarvitsemme C++ – kääntäjän. Tähän asennan GNU C++ – kääntäjän ” g++”:

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

yhden muun puuttuvan työkalun. Samat oireet. Sama ratkaisu:

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

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

menestys!

huomaa: Olen asentanut erilaisia työkaluja yksi kerrallaan näyttää, miten diagnoosi kokoelma kysymyksiä ja näyttää tyypillinen ratkaisu ratkaista näitä kysymyksiä. Mutta jos etsit lisätietoa aiheesta tai luet muita opetusohjelmia, huomaat, että useimmissa jakeluissa on ”metapaketteja”, jotka toimivat sateenvarjona joidenkin tai kaikkien tyypillisten ohjelmistojen kokoamiseen käytettävien työkalujen asentamiseksi. Debian-pohjaisissa järjestelmissä törmäät todennäköisesti build-essentials-pakettiin tätä tarkoitusta varten. Ja Red-Hat-pohjainen jakelut, että on ”kehitystyökalut” ryhmä.

Kentos 7.0

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

komentoa ei löydy? Asenna se vain käyttämällä yum paketinhallinta:

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

arvaat sen: nodejs kirjoitetaan C++ – kielellä, mutta minun järjestelmästäni puuttuu vastaava kääntäjä. Nami pelastaa. Koska en ole tavallinen CentOS-käyttäjä, minun piti itse asiassa etsiä Internetistä g++ – kääntäjän sisältävän paketin tarkka nimi. Johdattaen minut tuolle sivulle: 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

menestys. Uudelleen.

C. Jos teet muutoksia lähdekoodista asennettuun ohjelmistoon

, voit asentaa ohjelmiston lähteestä, koska tarvitset erityisen version, jota ei ole saatavilla jakeluvarastossasi, tai koska haluat muokata ohjelmaa korjataksesi vian tai lisätäksesi ominaisuuden. Loppujen lopuksi avoimessa lähdekoodissa on kyse muutosten tekemisestä. Niin, aion käyttää tätä tilaisuutta antaa sinulle esimakua valtaa sinulla on käsillä nyt, kun voit koota oman ohjelmiston.

tässä tehdään pieni muutos Nodejsin lähteisiin. Ja saa nähdä, sisällytetäänkö muutos ohjelmiston koottuun versioon:

avaa tiedosto node/src/node.cc suosikkitekstieditorissasi (vim, nano, gedit, … ). Ja yritä paikantaa tuo koodin katkelma:

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

se on tiedoston rivin 3830 tienoilla. Sitten muutetaan rivi, joka sisältää printf vastaamaan sitä sen sijaan:

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

suuntaa sitten takaisin päätelaitteellesi. Ennen kuin jatkat-ja saat lisää tietoa Gitin takana olevasta voimasta-voit tarkistaa, oletko muokannut oikeaa tiedostoa:

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

sinun pitäisi nähdä ” – ” (miinusmerkki) ennen viivaa sellaisena kuin se oli ennen sen muuttamista. Ja ” + ” (plus merkki) ennen linjaa muutosten jälkeen.

nyt on aika kääntää ja asentaa ohjelmistosi uudelleen:

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

tällä kertaa ainoa syy, miksi se saattaa epäonnistua, on se, että olet tehnyt kirjoitusvirheen muuttaessasi koodia. Jos näin on, avaa node/src/node.cc tiedosto uudelleen tekstieditorissa ja korjaa virhe.

Kun olet onnistunut kääntämään ja asentamaan uuden muokatun NodeJS-version, voit tarkistaa, onko muokkauksesi todella sisällytetty ohjelmistoon:

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

Onneksi olkoon! Olet tehnyt ensimmäisen muutoksen avoimen lähdekoodin ohjelmaan!

D. Anna komentotulkin paikantaa muokatut ohjelmistomme

olet ehkä huomannut, että olen aina käynnistänyt vastakääntämäni NodeJS-ohjelmiston määrittämällä absoluuttisen polun binääritiedostoon.

/opt/node/bin/node

se toimii. Mutta tämä on vähintäänkin ärsyttävää. On itse asiassa kaksi yleistä tapaa korjata se.

on itse asiassa kaksi yleistä tapaa korjata ärsyttävä ongelma määrittelemällä binääritiedostojen absoluuttinen polku,
, mutta ymmärtääksesi niitä sinun on ensin tiedettävä, että komentotulkki paikantaa suoritettavat tiedostot etsimällä niitä vain polku-ympäristömuuttujan määrittelemistä hakemistoista.

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

tässä Debian-järjestelmässä, jos et määrittele yksiselitteisesti mitään hakemistoa osana komentonimeä, komentotulkki etsii suoritettavat ohjelmat ensin /usr/local/bin, sitten jos ei löydy /usr/bin, niin jos ei löydy /bin then if not found into /usr/local/games then if not found into /usr/games, then if not found … the Shell ilmoittaa virheestä ”command not found”.

ottaen huomioon, että meillä on kaksi tapaa tehdä komento, joka on saatavilla komentotulkille: lisäämällä sen johonkin jo asetetuista PATH hakemistoista. Tai lisäämällä suoritettavan tiedostomme sisältävän kansion PATH.

linkin lisääminen /usr/local/bin

vain node-binääritiedoston kopioiminen /opt/node/bin/usr/local/bin olisi huono idea, koska näin tehdessään suoritettava ohjelma ei enää pystyisi paikantamaan muita vaadittuja /opt/node/ (on yleinen käytäntö, että ohjelmisto paikantaa resurssitiedostonsa suhteessa omaan sijaintiinsa).

perinteinen tapa tehdä se on käyttää symbolista linkkiä:

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

Tämä on yksinkertainen ja tehokas ratkaisu, varsinkin jos ohjelmistopaketti on tehty vain muutamasta tunnetusta suoritettavasta ohjelmasta— koska sinun täytyy luoda symbolinen linkki jokaiselle käyttäjän invokoitavalle komennolle. Jos esimerkiksi NodeJS on sinulle tuttu, tiedät npm companion application I should symlink from /usr/local/bin too. Mutta annoin sen sinulle harjoituksena.

polun muokkaaminen

ensin, jos kokeilit edeltävää ratkaisua, poista aiemmin luotu solmun symbolinen linkki, joka alkaa selkeästä tilasta:

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

ja nyt tässä on taikakomento muuttaa 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

yksinkertaisesti sanoin, että korvasin PATH ympäristömuuttujan sisällön sen aiemmalla sisällöllä, mutta etuliitteellä /opt/node/bin. Joten, kuten nyt voitte kuvitella, komentotulkki katsoo ensin /opt/node/bin hakemistoon suoritettaville ohjelmille. Voimme vahvistaa, että käyttämällä which komento:

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

kun taas ”linkki” – ratkaisu on pysyvä heti kun olet luonut symbolisen linkin /usr/local/binPATH muutos on tehokas vain nykyiseen komentotulkkiin. Jätän teidät hieman tutkimaan, miten tehdä muutoksia PATH permanentit. Vihjeenä, se on tekemistä ”profiili”. Jos löydät ratkaisun, älä epäröi jakaa sitä muille lukijoille käyttämällä alla olevaa kommenttiosiota!

E. Kuinka poistaa kyseinen vasta asennettu ohjelmisto lähdekoodista

koska mukautetusti koottu NodeJS-ohjelmisto istuu täysin /opt/node-v8.1.1 hakemistoon, kyseisen ohjelmiston poistaminen ei vaadi enempää vaivaa kuin RM-komennon käyttäminen kyseisen hakemiston poistamiseen:

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

varokaa: sudo ja rm -rf ovat vaarallinen cocktail! Tarkista komentosi aina kahdesti ennen kuin painat ”enter” – näppäintä. Sinulla ei ole vahvistusviestiä eikä undeletea jos poistat väärän hakemiston…

sitten, jos olet muokannut PATH, joudut perumaan nämä muutokset, mikä ei ole lainkaan monimutkaista.

ja jos olet luonut linkit /usr/local/bin joudut poistamaan ne kaikki:

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

odota? Missä oli Riippuvuushelvetti?

loppukommenttina, jos on lukenut oman muokatun ohjelmiston kokoamisesta, on saattanut kuulla riippuvuushelvetistä. Tämä on lempinimi sille ärsyttävälle tilanteelle, jossa ennen kuin pystyt kääntämään ohjelmiston onnistuneesti, sinun on ensin käännettävä ennakkoedellytys kirjasto, joka puolestaan vaatii toisen kirjaston, joka saattaa puolestaan olla yhteensopimaton joidenkin muiden jo asennettujen ohjelmistojen kanssa.

osa jakelusi pakettien ylläpitäjien työtä on ratkaista riippuvuushelvetti ja varmistaa, että järjestelmäsi eri ohjelmistot käyttävät yhteensopivia kirjastoja ja ovat asennettuina oikeassa järjestyksessä.

tähän artikkeliin valitsin tarkoituksella asentaa NodeJS: n, koska sillä ei käytännössä ole riippuvuuksia. Sanoin ”virtuaalisesti”, koska siinä on riippuvuuksia. Mutta näiden riippuvuuksien lähdekoodi on projektin lähdekoodivarastossa (node/deps alihakemisto), joten sinun ei tarvitse ladata ja asentaa niitä manuaalisesti ennen Handia.