Hoe software te installeren vanuit de broncode ... en daarna verwijderen

Briefing: deze gedetailleerde gids legt uit hoe u een programma uit broncode onder Linux installeert en hoe u de geïnstalleerde software uit de broncode verwijdert.

Een van de grootste voordelen van uw Linux-distributie is de pakketbeheerder en de bijbehorende softwarerepository. Met hen beschikt u over alle benodigde hulpmiddelen en hulpmiddelen om volledig geautomatiseerde nieuwe software op uw computer te downloaden en te installeren.

Maar ondanks al hun inspanningen kunnen de beheerders van het pakket niet elke gebruikssituatie aan. Ze kunnen ook niet alle beschikbare software verpakken. Er zijn dus nog steeds situaties waarin je zelf een nieuwe software moet compileren en installeren. Wat mijzelf betreft, de verreweg de meest voorkomende reden dat ik wat software moet compileren, is wanneer ik een heel specifieke versie moet uitvoeren. Of omdat ik de broncode wil wijzigen of een aantal mooie compilatie-opties wil gebruiken.

Als uw behoeften tot die laatste categorie behoren, zijn er kansen dat u al weet wat u doet. Maar voor de overgrote meerderheid van Linux-gebruikers kan het voor de eerste keer samenstellen en installeren van een software uit de bronnen een initiatieceremonie lijken: enigszins angstaanjagend; maar met de belofte om een ​​nieuwe wereld van mogelijkheden te betreden en deel uit te maken van een bevoorrechte gemeenschap als je dat overwint.

A. Software installeren met broncode onder Linux

En dat is precies wat we hier zullen doen. Laten we voor de toepassing van dit artikel zeggen dat ik NodeJS 8.1.1 op mijn systeem moet installeren. Die versie precies. Een versie die niet beschikbaar is in de Debian-repository:

sh$ apt-cache madison nodejs | grep amd64 nodejs | 6.11.1~dfsg-1 | //deb.debian.org/debian experimental/main amd64 Packages nodejs | 4.8.2~dfsg-1 | //ftp.fr.debian.org/debian stretch/main amd64 Packages nodejs | 4.8.2~dfsg-1~bpo8+1 | //ftp.fr.debian.org/debian jessie-backports/main amd64 Packages nodejs | 0.10.29~dfsg-2 | //ftp.fr.debian.org/debian jessie/main amd64 Packages nodejs | 0.10.29~dfsg-1~bpo70+1 | //ftp.fr.debian.org/debian wheezy-backports/main amd64 Packages 

Nu is het installeren van NodeJs op Ubuntu of Debian vrij eenvoudig als je het doet met de pakketbeheerder. Maar laten we het doen via de broncode.

Stap 1: De broncode ophalen via GitHub

Zoals vele open-sourceprojecten, zijn de bronnen van NodeJS te vinden op GitHub: //github.com/nodejs/node

Dus laten we daar direct heen gaan.

Als je niet bekend bent met GitHub, git of een ander versiecontrolesysteem dat de moeite van het vermelden waard is, bevat de repository de huidige bron voor de software, evenals een geschiedenis van alle aanpassingen die in de loop van de jaren aan die software zijn aangebracht. Uiteindelijk tot de allereerste regel geschreven voor dat project. Voor de ontwikkelaars heeft het bijhouden van die geschiedenis veel voordelen. Voor ons vandaag is de belangrijkste dat we in staat zullen zijn om de bronnen voor het project te krijgen zoals ze waren op een bepaald moment in de tijd. Nauwkeuriger gezegd, ik zal in staat zijn de bronnen te krijgen zoals ze waren toen de 8.1.1-versie die ik wilde, werd vrijgegeven. Zelfs als er sindsdien veel wijzigingen zijn doorgevoerd.

Op GitHub kunt u de knop "Filiaal" gebruiken om tussen verschillende versies van de software te navigeren. "Branch" en "tags" zijn enigszins verwante concepten in Git. Kortom, de ontwikkelaars maken "branch" en "tags" om belangrijke gebeurtenissen in de projectgeschiedenis bij te houden, zoals wanneer ze beginnen te werken aan een nieuwe functie of wanneer ze een release publiceren. Ik zal hier niet ingaan op de details, alles wat je moet weten is dat ik zoek naar de versie met de tag "v8.1.1"

Nadat u op de tag "v8.1.1" hebt gekozen, wordt de pagina vernieuwd. De meest voor de hand liggende wijziging is dat de tag nu als onderdeel van de URL wordt weergegeven. Bovendien zult u merken dat de datum voor het wijzigen van het bestand ook anders is. De bronstructuur die u nu ziet, is degene die bestond op het moment dat de tag v8.1.1 werd gemaakt. In zekere zin kun je een versiebeheerstool zoals git zien als een tijdreismachine, waardoor je heen en weer kunt gaan in een projectgeschiedenis.

Op dit punt kunnen we de bronnen van NodeJS 8.1.1 downloaden. Je kunt de grote blauwe knop niet missen die suggereert om het ZIP-archief van het project te downloaden. Vanaf mezelf zal ik de ZIP downloaden en uit de opdrachtregel halen voor de uitleg. Maar als u liever een GUI-tool gebruikt, aarzel dan niet om dat te doen:

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

Het downloaden van het ZIP-archief werkt prima. Maar als je het "als een professional" wilt doen, zou ik willen voorstellen om direct de git tool te gebruiken om de bronnen te downloaden. Het is helemaal niet ingewikkeld - en het zal een aardig eerste contact zijn met een tool die je vaak tegenkomt:

 # first ensure git is installed on your system sh$ sudo apt-get install git # Make a shallow clone the NodeJS repository at v8.1.1 sh$ git clone --depth 1 \ --branch v8.1.1 \ //github.com/nodejs/node sh$ cd node/ 

Trouwens, als je een probleem hebt, overweeg dan gewoon dat eerste deel van dit artikel als een algemene inleiding. Later heb ik meer gedetailleerde uitleg voor op Debian en RedHat gebaseerde distributies om u te helpen bij het oplossen van veelvoorkomende problemen.

Hoe dan ook, wanneer je de bron hebt gedownload met behulp van git of als een ZIP-archief, zou je nu exact dezelfde bronbestanden in de huidige map moeten hebben:

 sh$ ls android-configure BUILDING.md common.gypi doc Makefile src AUTHORS CHANGELOG.md configure GOVERNANCE.md node.gyp test benchmark CODE_OF_CONDUCT.md CONTRIBUTING.md lib node.gypi tools BSDmakefile COLLABORATOR_GUIDE.md deps LICENSE README.md vcbuild.bat 

Stap 2: Het buildsysteem van het programma begrijpen

We praten meestal over "compileren van de bronnen", maar de compilatie is slechts een van de fasen die nodig zijn om een ​​werkende software uit de bron te produceren. Een build-systeem is een set hulpprogramma's en -praktijken die worden gebruikt om die verschillende taken te automatiseren en te articuleren om de software geheel te bouwen door slechts enkele opdrachten uit te voeren.

Als het concept eenvoudig is, is de realiteit iets gecompliceerder. Omdat verschillende projecten of programmeertaal verschillende vereisten kunnen hebben. Of vanwege de smaak van de programmeur. Of de ondersteunde platforms. Of om historische reden. Of ... of .. er is een bijna eindeloze lijst met redenen om een ​​ander buildsysteem te kiezen of te maken. Dat alles om te zeggen dat er veel verschillende oplossingen worden gebruikt die er zijn.

NodeJS gebruikt een buildsysteem in GNU-stijl. Dit is een populaire keuze in de open-sourcecommunity. En nogmaals, een goede manier om je reis te beginnen.

Het schrijven en afstemmen van een build-systeem is een behoorlijk complexe taak. Maar voor de 'eindgebruiker' gaan de GNU-achtige build-systemen verder met het gebruik van twee tools: configure en make .

Het configure is een projectspecifiek script dat de configuratie van het bestemmingsysteem en de beschikbare functie controleert om ervoor te zorgen dat het project kan worden gebouwd, waarbij uiteindelijk de specifieke kenmerken van het huidige platform worden behandeld.

Een belangrijk onderdeel van een typische configure is het bouwen van de Makefile . Dat is het bestand met de instructies die nodig zijn om het project effectief te bouwen.

De make tool), aan de andere kant, is een POSIX-tool beschikbaar op elk Unix-achtig systeem. Het zal de projectspecifieke Makefile en de vereiste bewerkingen uitvoeren om uw programma te bouwen en te installeren.

Maar zoals altijd in de Linux-wereld, heb je nog steeds enige latentie om de build aan te passen aan jouw specifieke behoeften.

 ./configure --help 

De configure -help opdracht toont u alle beschikbare configuratie-opties. Nogmaals, dit is erg projectspecifiek. En om eerlijk te zijn, is het soms nodig om in het project te graven voordat je de betekenis van elke configuratie-optie volledig begrijpt.

Maar er is tenminste één standaard GNU Autotools-optie die je moet weten: de optie --prefix . Dit heeft te maken met de bestandssysteemhiërarchie en de plaats waar uw software zal worden geïnstalleerd.

Stap 3: De FHS

De hiërarchie van het Linux-bestandssysteem op een typische distributie voldoet meestal aan de Filesystem Hierarchy Standard (FHS)

Die standaard verklaart het doel van de verschillende mappen van uw systeem: /usr, /tmp, /var enzovoort.

Als u de GNU Autotools- en de meeste andere build-systemen gebruikt, is de standaard installatielocatie voor uw nieuwe software /usr/local . Wat een goede keuze is volgens de FSH "De / usr / lokale hiërarchie is voor gebruik door de systeembeheerder bij het lokaal installeren van software? Het moet veilig zijn om te worden overschreven wanneer de systeemsoftware wordt bijgewerkt. Het kan worden gebruikt voor programma's en gegevens die deelbaar zijn tussen een groep hosts, maar niet worden gevonden in / usr. "

De /usr/local hiërarchie repliceert op een of andere manier de hoofdmap, en u zult daar /usr/local/bin voor de uitvoerbare programma's, /usr/local/lib voor de bibliotheken, /usr/local/share voor architectuur onafhankelijke bestanden en zo op.

Het enige probleem bij het gebruik van de /usr/local tree voor aangepaste software-installatie is dat de bestanden voor al uw software daar worden gemengd. Vooral na het installeren van een aantal software zal het moeilijk zijn om te volgen naar welk bestand van /usr/local/bin en /usr/local/lib precies die software hoort. Dat zal echter geen probleem voor het systeem veroorzaken. Immers, /usr/bin is ongeveer dezelfde rotzooi. Maar dat zal een probleem worden op de dag dat u een handmatig geïnstalleerde software wilt verwijderen.

Om dat probleem op te lossen, geef ik meestal de voorkeur aan het installeren van aangepaste software in de submap /opt . Nogmaals, om de FHS te citeren:

_ "/ Opt is gereserveerd voor de installatie van softwarepakketten voor add-on applicaties.

Een pakket dat moet worden geïnstalleerd in / opt, moet zijn statische bestanden vinden in een aparte / opt / or / opt / directory-structuur, waar is een naam die het softwarepakket beschrijft en de LANANA-geregistreerde naam van de provider is. "_

Dus zullen we een submap maken van /opt specifiek voor onze aangepaste NodeJS-installatie. En als ik op een dag die software wil verwijderen, zal ik gewoon die map moeten verwijderen:

 sh$ sudo mkdir /opt/node-v8.1.1 sh$ sudo ln -sT node-v8.1.1 /opt/node # What is the purpose of the symbolic link above? # Read the article till the end--then try to answer that # question in the comment section! sh$ ./configure --prefix=/opt/node-v8.1.1 sh$ make -j9 && echo ok # -j9 means run up to 9 parallel tasks to build the software. # As a rule of thumb, use -j(N+1) where N is the number of cores # of your system. That will maximize the CPU usage (one task per # CPU thread/core + a provision of one extra task when a process # is blocked by an I/O operation. 

Alles behalve "ok" nadat de opdracht make is voltooid, betekent dat er een fout is opgetreden tijdens het buildproces. Omdat we een parallelle build draaiden vanwege de optie -j, is het niet altijd eenvoudig om de foutmelding te achterhalen gezien het grote volume van de uitvoer geproduceerd door het buildsysteem.

In het geval van een probleem, herstart make, maar zonder de -j optie deze keer. En de fout moet verschijnen aan het einde van de uitvoer:

 sh$ make 

Eindelijk, als de compilatie eenmaal is voltooid, kunt u uw software op de locatie installeren door de opdracht uit te voeren:

 sh$ sudo make install 

En test het:

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

B. Wat als er dingen fout gaan tijdens het installeren vanaf de broncode?

Wat ik hierboven heb uitgelegd, is meestal wat je kunt zien op de pagina "bouwinstructie" van een goed gedocumenteerd project. Maar gezien dit artikeldoel is om u uw eerste software uit bronnen te laten samenstellen, is het misschien de moeite waard de tijd te nemen om enkele veelvoorkomende problemen te onderzoeken. Dus ik zal de hele procedure opnieuw doen, maar deze keer van een nieuw en minimaal Debian 9.0- en CentOS 7.0-systeem. Dus je kunt de fout zien die ik tegenkwam en hoe ik ze heb opgelost.

Van Debian 9.0 "Stretch"

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

Dit probleem is vrij eenvoudig te diagnosticeren en op te lossen. Installeer gewoon het git pakket:

 [email protected]:~$ sudo apt-get install git 
 [email protected]:~$ git clone --depth 1 \ --branch v8.1.1 \ //github.com/nodejs/node && echo ok [...] ok 
 [email protected]:~/node$ sudo mkdir /opt/node-v8.1.1 [email protected]:~/node$ sudo ln -sT node-v8.1.1 /opt/node 

Geen probleem hier.

 [email protected]:~/node$ ./configure --prefix=/opt/node-v8.1.1/ WARNING: failed to autodetect C++ compiler version (CXX=g++) WARNING: failed to autodetect C compiler version (CC=gcc) Node.js configure error: No acceptable C compiler found! Please make sure you have a C compiler installed on your system and/or consider adjusting the CC environment variable if you installed it in a non-standard prefix. 

Uiteraard hebt u voor het samenstellen van een project een compiler nodig. NodeJS wordt geschreven met behulp van de C ++ taal, we hebben een C ++ compiler nodig. Hier installeer ik `g ++`, de GNU C ++ -compiler voor dat doel:

 [email protected]:~/node$ sudo apt-get install g++ [email protected]:~/node$ ./configure --prefix=/opt/node-v8.1.1/ && echo ok [...] ok 
 [email protected]:~/node$ make -j9 && echo ok -bash: make: command not found 

Nog een ander ontbrekend gereedschap. Dezelfde symptomen. Dezelfde oplossing:

 [email protected]:~/node$ sudo apt-get install make [email protected]:~/node$ make -j9 && echo ok [...] ok 
 [email protected]:~/node$ sudo make install [...] [email protected]:~/node$ /opt/node/bin/node --version v8.1.1 

Succes!

Let op: ik heb de verschillende tools één voor één geïnstalleerd om te laten zien hoe de compilatieproblemen kunnen worden gesteld en om u de typische oplossing voor het oplossen van deze problemen te tonen. Maar als u meer over dat onderwerp zoekt of andere zelfstudies leest, zult u ontdekken dat de meeste distributies "metapakketten" hebben als een paraplu om enkele of alle typische hulpmiddelen te installeren die worden gebruikt voor het compileren van een software. Op Debian-gebaseerde systemen kom je waarschijnlijk het build-essentials-pakket tegen. En op Red-Hat-gebaseerde distributies, dat zal de groep "Development Tools" zijn.

Van CentOS 7.0

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

Opdracht niet gevonden? Installeer het gewoon met behulp van de yum package manager:

 [[email protected] ~]$ sudo yum install git 
 [[email protected] ~]$ git clone --depth 1 \ --branch v8.1.1 \ //github.com/nodejs/node && echo ok [...] ok 
 [[email protected] ~]$ sudo mkdir /opt/node-v8.1.1 [[email protected] ~]$ sudo ln -sT node-v8.1.1 /opt/node 
 [[email protected] ~]$ cd node [[email protected] node]$ ./configure --prefix=/opt/node-v8.1.1/ WARNING: failed to autodetect C++ compiler version (CXX=g++) WARNING: failed to autodetect C compiler version (CC=gcc) Node.js configure error: No acceptable C compiler found! Please make sure you have a C compiler installed on your system and/or consider adjusting the CC environment variable if you installed it in a non-standard prefix. 

Je raadt het: NodeJS is geschreven met de C ++ -taal, maar mijn systeem mist de bijbehorende compiler. Yum om te redden. Omdat ik geen gewone CentOS-gebruiker ben, moest ik eigenlijk op internet de exacte naam van het pakket met de g ++ -compiler opzoeken. Ik leid naar die pagina: //superuser.com/questions/590808/yum-install-gcc-g-doesnt-work-anymore-in-centos-6-4

 [[email protected] node]$ sudo yum install gcc-c++ [[email protected] node]$ ./configure --prefix=/opt/node-v8.1.1/ && echo ok [...] ok 
 [[email protected] node]$ make -j9 && echo ok [...] ok 
 [[email protected] node]$ sudo make install && echo ok [...] ok 
 [[email protected] node]$ /opt/node/bin/node --version v8.1.1 

Succes. Nog een keer.

C. Wijzigingen aanbrengen in de software die is geïnstalleerd vanuit de broncode

U mag een software van de bron installeren, omdat u een zeer specifieke versie nodig heeft die niet beschikbaar is in uw distributiearchief. Of omdat u dat programma wilt wijzigen . Ofwel om een ​​bug te repareren of om een ​​functie toe te voegen. Open source gaat daar tenslotte allemaal over. Dus ik zal die gelegenheid aangrijpen om je een voorproefje te geven van de kracht die je bij de hand hebt nu je in staat bent om je eigen software te compileren.

Hier zullen we een kleine wijziging aanbrengen in de bronnen van NodeJS. En we zullen zien of onze wijziging zal worden opgenomen in de gecompileerde versie van de software:

Open het bestandsknooppunt node/src/node.cc in uw favoriete teksteditor (vim, nano, gedit, ...). En probeer dat fragment van code te vinden:

  if (debug_options.ParseOption(argv[0], arg)) { // Done, consumed by DebugOptions::ParseOption(). } else if (strcmp(arg, "--version") == 0 || strcmp(arg, "-v") == 0) { printf("%s\n", NODE_VERSION); exit(0); } else if (strcmp(arg, "--help") == 0 || strcmp(arg, "-h") == 0) { PrintHelp(); exit(0); } 

Het staat rond regel 3830 van het bestand. Pas dan de regel met printf aan zodat deze overeenkomt met die in plaats daarvan:

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

Ga dan terug naar je terminal. Voordat je verder gaat - en om je meer inzicht te geven in de kracht achter git - kun je controleren of je het juiste bestand hebt aangepast:

 diff --git a/src/node.cc b/src/node.cc index bbce1022..a5618b57 100644 --- a/src/node.cc +++ b/src/node.cc @@ -3828, 7 +3828, 7 @@ static void ParseArgs(int* argc, if (debug_options.ParseOption(argv[0], arg)) { // Done, consumed by DebugOptions::ParseOption(). } else if (strcmp(arg, "--version") == 0 || strcmp(arg, "-v") == 0) { - printf("%s\n", NODE_VERSION); + printf("%s (compiled by myself)\n", NODE_VERSION); exit(0); } else if (strcmp(arg, "--help") == 0 || strcmp(arg, "-h") == 0) { PrintHelp(); 

U zou een "-" (minteken) vóór de regel moeten zien zoals deze was voordat u deze veranderde. En een "+" (plusteken) vóór de regel na uw wijzigingen.

Het is nu tijd om uw software te hercompileren en opnieuw te installeren:

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

Deze keer is de enige reden dat het kan mislukken, is dat je een typfout hebt gemaakt tijdens het wijzigen van de code. Als dit het geval is, opent u het node/src/node.cc bestand opnieuw in uw teksteditor en verhelpt u de fout.

Nadat je die nieuwe gemodificeerde NodeJS-versie hebt kunnen compileren en installeren, kun je controleren of je wijzigingen daadwerkelijk in de software zijn opgenomen:

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

Gefeliciteerd! U hebt uw eerste wijziging in een open-sourceprogramma gemaakt!

D. Laat de shell onze aangepaste build-software vinden

U hebt misschien gemerkt dat ik tot nu toe mijn nieuw gecompileerde NodeJS-software altijd lanceerde door het absolute pad naar het binaire bestand op te geven.

 /opt/node/bin/node 

Het werkt. Maar dit is op zijn zachtst gezegd vervelend. Er zijn eigenlijk twee veel voorkomende manieren om dat te verhelpen. Maar om ze te begrijpen, moet u eerst weten dat uw shell de uitvoerbare bestanden lokaliseert door ze alleen te zoeken in de mappen die zijn opgegeven door de omgevingsvariabele PATH .

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

Hier, op dat Debian-systeem, als je niet expliciet een map opgeeft als onderdeel van een commandonaam, zal de shell eerst naar die uitvoerbare programma's zoeken in /usr/local/bin, en als die niet wordt gevonden in /usr/bin, dan indien niet gevonden in /bin dan indien niet gevonden in /usr/local/games en indien niet gevonden in /usr/games, dan indien niet gevonden ... zal de shell een fout rapporteren "commando niet gevonden" .

Gegeven dat we twee mogelijkheden hebben om een ​​commando toegankelijk te maken voor de shell: door het toe te voegen aan een van de reeds geconfigureerde PATH directory's. Of door de map met ons uitvoerbare bestand toe te voegen aan het PATH .

Een link toevoegen vanuit / usr / local / bin

Gewoon het kopiëren van het knooppunt binaire uitvoerbare bestand van /opt/node/bin naar /usr/local/bin zou een slecht idee zijn, omdat door dit te doen, het uitvoerbare programma niet langer in staat zou zijn om de andere vereiste componenten te vinden die behoren tot /opt/node/ (het is een gangbare praktijk voor een software om de bronbestanden ten opzichte van zijn eigen locatie te lokaliseren).

Dus, de traditionele manier om dat te doen is door een symbolische link te gebruiken:

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

Dit is een eenvoudige en effectieve oplossing, vooral als een softwarepakket is gemaakt van slechts enkele bekende uitvoerbare programma's, aangezien u een symbolische koppeling moet maken voor elke door de gebruiker aanroepbare opdracht. Als u bijvoorbeeld bekend bent met NodeJS, weet u de npm begeleidende toepassing die ik ook moet koppelen aan /usr/local/bin . Maar ik heb dat jou als een oefening toegestaan.

Het PATH aanpassen

Ten eerste, als u de voorgaande oplossing hebt geprobeerd, verwijdert u de symbolische koppeling van het knooppunt die eerder is gemaakt om vanuit een lege staat te beginnen:

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

En nu, hier is het magische commando om je PATH te veranderen:

 [email protected]:~/node$ export PATH="/opt/node/bin:${PATH}" [email protected]:~/node$ echo $PATH /opt/node/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games 

Eenvoudig gezegd, ik heb de inhoud van de PATH omgevingsvariabele vervangen door de vorige inhoud, maar voorafgegaan door /opt/node/bin . Dus, zoals je je nu kunt voorstellen, zal de shell eerst kijken naar de /opt/node/bin directory voor uitvoerbare programma's. We kunnen bevestigen dat met het volgende commando:

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

Terwijl de "link" -oplossing permanent is, zodra u de symbolische link in /usr/local/bin, is de PATH wijziging alleen effectief in de huidige shell. Ik heb je enkele onderzoeken laten doen om te weten hoe je de PATH permanenten kunt wijzigen. Als een hint heeft het te maken met je "profiel". Als je de oplossing vindt, aarzel dan niet om dat te delen met de andere lezers door het commentaar hieronder te gebruiken!

E. Hoe die nieuw geïnstalleerde software uit de broncode te verwijderen

Omdat onze op maat gemaakte NodeJS-software volledig in de map /opt/node-v8.1.1 zit, is het verwijderen van die software niet meer dan het gebruik van de opdracht rm om die map te verwijderen:

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

PAS OP: sudo en rm -rf zijn een gevaarlijke cocktail! Controleer uw opdracht altijd twee keer voordat u op de "Enter" -toets drukt. U zult geen bevestigingsbericht hebben en niet ongedaan maken als u de verkeerde map verwijdert ...

Als u vervolgens uw PATH hebt gewijzigd, moet u die wijzigingen terugdraaien. Wat helemaal niet ingewikkeld is.

En als je links hebt gemaakt van /usr/local/bin dan moet je ze allemaal verwijderen:

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

Wacht? Waar was de afhankelijkheidshel?

Als laatste opmerking, als je leest over het compileren van je eigen aangepaste software, heb je misschien gehoord van de afhankelijkheids hel. Dit is een bijnaam voor die vervelende situatie. Voordat u een software met succes kunt compileren, moet u eerst een vooraf benodigde bibliotheek compileren, die op zijn beurt weer een andere bibliotheek vereist die op zijn beurt incompatibel kan zijn met andere software die u al hebt geïnstalleerd.

Een deel van de taak van de pakketbeheerders van uw distributie is om die afhankelijkheid helemaal op te lossen en ervoor te zorgen dat de verschillende software van uw systeem compatibele bibliotheken gebruiken en in de juiste volgorde worden geïnstalleerd.

In dat artikel koos ik expres om NodeJS te installeren omdat het vrijwel geen afhankelijkheden heeft. Ik zei "virtueel" omdat het in feite afhankelijkheden heeft. Maar de broncode van die afhankelijkheden is aanwezig in de node/deps van het project (in de submap node/deps ), zodat u ze niet handmatig hoeft te downloaden en installeren.

Maar als je geïnteresseerd bent om meer over dat probleem te weten te komen en te leren hoe ermee om te gaan, laat me dan weten dat je de onderstaande commentaarsectie gebruikt: dat zou een geweldig onderwerp zijn voor een geavanceerder artikel!

Aanbevolen

Installeer Adobe Lightroom Alternatieve RawTherapee in Ubuntu
2019
Download 15 prachtige sexy achtergronden van Debian
2019
Gebruik de modus Niet storen in Ubuntu met NoNotifications
2019