So installieren Sie Software aus dem Quellcode… und entfernen sie anschließend

Kurz: In diesem ausführlichen Handbuch wird erläutert, wie Sie ein Programm aus dem Quellcode unter Linux installieren und die installierte Software aus dem Quellcode entfernen.

Eine der größten Stärken Ihrer Linux-Distribution ist der Paketmanager und das zugehörige Software-Repository. Mit ihnen verfügen Sie über alle notwendigen Tools und Ressourcen, um eine neue Software vollständig automatisiert auf Ihren Computer herunterzuladen und zu installieren.

Trotz aller Bemühungen können die Paketbetreuer nicht jeden Anwendungsfall bearbeiten. Sie können auch nicht die gesamte verfügbare Software packen. Es gibt also immer noch Situationen, in denen Sie eine neue Software selbst kompilieren und installieren müssen. Ich selbst bin der häufigste Grund dafür, dass ich Software kompilieren muss, wenn ich eine bestimmte Version ausführen muss. Oder weil ich den Quellcode ändern oder ausgefallene Kompilierungsoptionen verwenden möchte.

Wenn Ihre Bedürfnisse in die letztere Kategorie fallen, wissen Sie wahrscheinlich bereits, was Sie tun. Für die überwiegende Mehrheit der Linux-Benutzer könnte das erste Kompilieren und Installieren einer Software aus den Quellen jedoch wie eine Einweihungszeremonie aussehen: etwas beängstigend; aber mit dem Versprechen, in eine neue Welt der Möglichkeiten einzutreten und Teil einer privilegierten Gemeinschaft zu sein, wenn Sie dies überwinden.

A. Installieren von Software aus dem Quellcode unter Linux

Und genau das werden wir hier tun. Nehmen wir für den Zweck dieses Artikels an, dass ich NodeJS 8.1.1 auf meinem System installieren muss. Genau diese Version. Eine Version, die nicht im Debian-Repository verfügbar ist:

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 

Jetzt ist die Installation von NodeJs unter Ubuntu oder Debian ziemlich einfach, wenn Sie dies mit dem Paketmanager tun. Aber lass es uns über den Quellcode machen.

Schritt 1: Holen Sie sich den Quellcode von GitHub

Wie bei vielen Open-Source-Projekten finden Sie die Quellen von NodeJS auf GitHub: //github.com/nodejs/node

Lass uns also direkt dorthin gehen.

Wenn Sie nicht mit GitHub, Git oder einem anderen Versionskontrollsystem vertraut sind, das erwähnenswert ist, enthält das Repository die aktuelle Quelle für die Software sowie einen Verlauf aller Änderungen, die im Laufe der Jahre an dieser Software vorgenommen wurden. Irgendwann bis zur allerersten Zeile, die für dieses Projekt geschrieben wurde. Für die Entwickler hat es viele Vorteile, diese Geschichte zu führen. Für uns heute ist die Hauptsache, dass wir in der Lage sein werden, die Quellen für das Projekt so zu beschaffen, wie sie zu einem bestimmten Zeitpunkt waren. Genauer gesagt, ich kann die Quellen so abrufen, wie sie waren, als die von mir gewünschte Version 8.1.1 veröffentlicht wurde. Auch wenn es seitdem viele Änderungen gab.

Auf GitHub können Sie über die Schaltfläche "Verzweigen" zwischen verschiedenen Versionen der Software navigieren. "Branch" und "Tags" sind in Git verwandte Begriffe. Grundsätzlich erstellen die Entwickler "Branch" und "Tags", um wichtige Ereignisse in der Projekthistorie zu verfolgen, z. B. wenn sie mit der Arbeit an einem neuen Feature beginnen oder wenn sie eine Veröffentlichung veröffentlichen. Ich werde hier nicht auf die Details eingehen. Alles, was Sie wissen müssen, ist, dass ich nach der Version mit dem Tag "v8.1.1" suche.

Nach Auswahl des Tags „v8.1.1“ wird die Seite aktualisiert. Die offensichtlichste Änderung ist, dass das Tag jetzt als Teil der URL angezeigt wird. Außerdem werden Sie feststellen, dass das Änderungsdatum der Datei ebenfalls unterschiedlich ist. Der Quellbaum, den Sie jetzt sehen, war zum Zeitpunkt der Erstellung des v8.1.1-Tags vorhanden. In gewisser Weise können Sie sich ein Tool zur Versionskontrolle wie git als Zeitreise-Maschine vorstellen, mit dem Sie in einer Projektgeschichte vor- und zurückblättern können.

Zu diesem Zeitpunkt können wir die Quellen von NodeJS 8.1.1 herunterladen. Sie können den großen blauen Knopf nicht verfehlen, der vorschlägt, das ZIP-Archiv des Projekts herunterzuladen. Ich selbst werde die ZIP-Datei herunterladen und aus der Befehlszeile extrahieren, um die Erklärung zu erhalten. Wenn Sie es jedoch vorziehen, ein GUI-Tool zu verwenden, zögern Sie nicht, dies zu tun:

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

Das Herunterladen des ZIP-Archivs funktioniert hervorragend. Aber wenn Sie es "wie ein Profi" machen wollen, würde ich vorschlagen, das git Tool direkt zu verwenden, um die Quellen herunterzuladen. Es ist überhaupt nicht kompliziert - und es wird ein netter erster Kontakt mit einem Werkzeug sein, auf das Sie häufig stoßen werden:

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

Wenn Sie ein Problem haben, betrachten Sie den ersten Teil dieses Artikels als allgemeine Einführung. Später habe ich detailliertere Erklärungen für Debian- und RedHat-basierte Distributionen, um Ihnen bei der Behebung häufiger Probleme zu helfen.

Wie auch immer, wenn Sie die Quelle mit git oder als ZIP-Archiv heruntergeladen haben, sollten Sie jetzt genau dieselben Quelldateien im aktuellen Verzeichnis haben:

 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 

Schritt 2: Das Build-System des Programms verstehen

Wir sprechen normalerweise über das „Kompilieren der Quellen“, aber das Kompilieren ist nur eine der Phasen, die erforderlich sind, um eine funktionierende Software aus der Quelle zu erstellen. Ein Build-System besteht aus einer Reihe von Tools und Methoden, mit denen diese verschiedenen Aufgaben automatisiert und artikuliert werden, um die Software vollständig zu erstellen, indem nur wenige Befehle eingegeben werden.

Wenn das Konzept einfach ist, ist die Realität etwas komplizierter. Weil unterschiedliche Projekte oder Programmiersprachen unterschiedliche Anforderungen haben können. Oder wegen des Geschmacks des Programmierers. Oder die unterstützten Plattformen. Oder aus historischem Grund. Oder ... oder ... es gibt eine fast endlose Liste von Gründen, ein anderes Build-System auszuwählen oder zu erstellen. All das, um zu sagen, es gibt viele verschiedene Lösungen.

NodeJS verwendet ein GNU-artiges Build-System. Dies ist eine beliebte Wahl in der Open Source-Community. Und noch einmal, ein guter Weg, um Ihre Reise zu beginnen.

Das Schreiben und Optimieren eines Build-Systems ist eine ziemlich komplexe Aufgabe. Aber für den "Endbenutzer" verwenden GNU-artige Build-Systeme wieder zwei Tools: configure und make .

Die configure ist ein projektspezifisches Skript, das die Konfiguration des Zielsystems und die verfügbaren Funktionen überprüft, um sicherzustellen, dass das Projekt erstellt werden kann, und schließlich die Besonderheiten der aktuellen Plattform berücksichtigt.

Ein wichtiger Teil eines typischen configure ist das Erstellen des Makefile . Dies ist die Datei mit den Anweisungen, die zum effektiven Erstellen des Projekts erforderlich sind.

Das make Tool ist ein POSIX-Tool, das auf jedem Unix-ähnlichen System verfügbar ist. Es liest das projektspezifische Makefile und führt die erforderlichen Vorgänge aus, um Ihr Programm zu erstellen und zu installieren.

Wie immer in der Linux-Welt haben Sie jedoch eine gewisse Latenz, um den Build an Ihre spezifischen Anforderungen anzupassen.

 ./configure --help 

Der Befehl configure -help zeigt Ihnen alle verfügbaren Konfigurationsoptionen an. Dies ist wiederum sehr projektspezifisch. Und um ehrlich zu sein, ist es manchmal erforderlich, sich mit dem Projekt zu befassen, bevor die Bedeutung jeder einzelnen Konfigurationsoption vollständig verstanden wird.

Es gibt jedoch mindestens eine Standardoption von GNU Autotools, die Sie kennen müssen: die Option --prefix . Dies hat mit der Dateisystemhierarchie und dem Ort zu tun, an dem Ihre Software installiert wird.

Schritt 3: Die FHS

Die Linux-Dateisystemhierarchie auf einer typischen Distribution entspricht größtenteils dem Filesystem Hierarchy Standard (FHS).

Dieser Standard erklärt den Zweck der verschiedenen Verzeichnisse Ihres Systems: /usr, /tmp, /var und so weiter.

Bei Verwendung der GNU Autotools - und der meisten anderen Build-Systeme - lautet der Standardinstallationspfad für Ihre neue Software /usr/local . Was ist eine gute Wahl, da laut FSH „Die / usr / local-Hierarchie vom Systemadministrator für die lokale Installation von Software verwendet wird? Es muss sicher sein, dass es beim Aktualisieren der Systemsoftware nicht überschrieben wird. Es kann für Programme und Daten verwendet werden, die von einer Gruppe von Hosts gemeinsam genutzt werden können, sich jedoch nicht in / usr befinden. “

Die /usr/local Hierarchie repliziert irgendwie das Stammverzeichnis und Sie finden dort /usr/local/bin für die ausführbaren Programme, /usr/local/lib für die Bibliotheken, /usr/local/share für architekturunabhängige Dateien und so weiter auf.

Das einzige Problem bei der Verwendung des /usr/local Baums für die benutzerdefinierte Softwareinstallation ist, dass die Dateien für Ihre gesamte Software dort gemischt werden. Insbesondere nach der Installation einiger Software ist es schwierig zu ermitteln, in welcher Datei genau /usr/local/bin und /usr/local/lib zu welcher Software gehört. Dies wird jedoch keine Probleme für das System verursachen. Immerhin ist /usr/bin ungefähr das gleiche Durcheinander. Dies wird jedoch zu einem Problem, wenn Sie eine manuell installierte Software entfernen möchten.

Um dieses Problem zu lösen, ziehe ich es normalerweise vor, benutzerdefinierte Software in der /opt -Teilstruktur zu installieren. Nochmals, um die FHS zu zitieren:

_ ”/ Opt ist für die Installation von Add-On-Anwendungssoftwarepaketen reserviert.

Ein Paket, das in / opt installiert werden soll, muss seine statischen Dateien in einem separaten Verzeichnisbaum / opt / oder / opt / ablegen. Dabei handelt es sich um einen Namen, der das Softwarepaket beschreibt und den LANANA-registrierten Namen des Anbieters. “_

Daher erstellen wir ein Unterverzeichnis von /opt speziell für unsere benutzerdefinierte NodeJS-Installation. Und wenn ich eines Tages diese Software entfernen möchte, muss ich einfach dieses Verzeichnis entfernen:

 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 andere als „ok“, nachdem der Befehl make ausgeführt wurde, bedeutet, dass während des Erstellungsvorgangs ein Fehler aufgetreten ist. Da wir aufgrund der Option -j einen parallelen Build ausgeführt haben, ist es nicht immer einfach, die Fehlermeldung abzurufen, da das Build-System eine große Menge an Ausgaben erzeugt.

Im Falle eines Problems starten Sie make einfach neu, diesmal jedoch ohne die Option -j . Und der Fehler sollte gegen Ende der Ausgabe erscheinen:

 sh$ make 

Sobald die Kompilierung abgeschlossen ist, können Sie Ihre Software an ihrem Speicherort installieren, indem Sie den folgenden Befehl ausführen:

 sh$ sudo make install 

Und teste es:

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

B. Was ist, wenn bei der Installation aus dem Quellcode Probleme auftreten?

Was ich oben erklärt habe, ist hauptsächlich das, was Sie auf der Seite "Bauanleitung" eines gut dokumentierten Projekts sehen können. Angesichts des Ziels dieses Artikels, dass Sie Ihre erste Software aus Quellen kompilieren können, lohnt es sich möglicherweise, einige häufig auftretende Probleme zu untersuchen. Also werde ich den gesamten Vorgang wiederholen, diesmal jedoch von einem neuen und minimalen Debian 9.0- und CentOS 7.0-System. So können Sie sehen, auf welchen Fehler ich gestoßen bin und wie ich sie gelöst habe.

Aus Debian 9.0 "Strecken"

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

Dieses Problem ist recht einfach zu diagnostizieren und zu lösen. Installieren Sie einfach das git Paket:

 [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 

Kein Problem 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. 

Um ein Projekt zu kompilieren, benötigen Sie natürlich einen Compiler. Da NodeJS in der C ++ - Sprache geschrieben wurde, benötigen wir einen C ++ - Compiler. Hier werde ich `g ++` installieren, den GNU C ++ - Compiler für diesen Zweck:

 [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 

Ein weiteres fehlendes Werkzeug. Gleiche Symptome. Gleiche Lösung:

 [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 

Erfolg!

Bitte beachten Sie: Ich habe die verschiedenen Tools nacheinander installiert, um zu zeigen, wie die Kompilierungsprobleme diagnostiziert werden und um Ihnen die typische Lösung für diese Probleme zu zeigen. Wenn Sie jedoch mehr zu diesem Thema suchen oder andere Tutorials lesen, werden Sie feststellen, dass die meisten Distributionen „Metapakete“ als Dach haben, um einige oder alle typischen Tools zu installieren, die zum Kompilieren einer Software verwendet werden. Auf Debian-basierten Systemen werden Sie wahrscheinlich auf das Build-Essentials-Paket für diesen Zweck stoßen. Bei Red-Hat-basierten Distributionen ist dies die Gruppe „Development Tools“ .

Ab CentOS 7.0

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

Befehl nicht gefunden? Installiere es einfach mit dem yum Paketmanager:

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

Sie vermuten es: NodeJS ist in der Sprache C ++ geschrieben, aber meinem System fehlt der entsprechende Compiler. Lecker zur Rettung. Da ich kein normaler CentOS-Benutzer bin, musste ich im Internet nach dem genauen Namen des Pakets suchen, das den g ++ - Compiler enthält. Führe mich zu dieser Seite: //superuser.com/questions/590808/yum-install-gcc-g-doesnt-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 

Erfolg. Nochmal.

C. Vornehmen von Änderungen an der aus dem Quellcode installierten Software

Sie können eine Software von der Quelle installieren, da Sie eine sehr spezielle Version benötigen, die in Ihrem Distributions-Repository nicht verfügbar ist. Oder weil Sie dieses Programm ändern möchten. Entweder um einen Fehler zu beheben oder um eine Funktion hinzuzufügen. Bei Open Source geht es schließlich darum. Ich werde diese Gelegenheit nutzen, um Ihnen einen Eindruck von der Macht zu geben, die Sie jetzt zur Hand haben, wenn Sie in der Lage sind, Ihre eigene Software zu kompilieren.

Hier nehmen wir eine kleine Änderung an den Quellen von NodeJS vor. Und wir werden sehen, ob unsere Änderung in die kompilierte Version der Software aufgenommen wird:

Öffnen Sie die Datei node/src/node.cc in Ihrem bevorzugten Texteditor (vim, nano, gedit, …). Und versuchen Sie, dieses Codefragment zu finden:

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

Es handelt sich um die Zeile 3830 der Datei. Ändern Sie dann die Zeile, die printf, so, dass sie dieser Zeile entspricht:

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

Gehen Sie dann zurück zu Ihrem Terminal. Bevor Sie fortfahren - und Ihnen einen Einblick in die Leistungsfähigkeit von git geben - können Sie überprüfen, ob Sie die richtige Datei geändert haben:

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

Sie sollten ein "-" (Minuszeichen) vor der Zeile sehen, wie es war, bevor Sie es geändert haben. Und ein "+" (Pluszeichen) vor der Zeile nach Ihren Änderungen.

Jetzt ist es Zeit, Ihre Software neu zu kompilieren und zu installieren:

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

Diesmal ist der einzige Grund, warum dies fehlschlagen könnte, dass Sie beim Ändern des Codes einen Tippfehler gemacht haben. Wenn dies der Fall ist, öffnen Sie die Datei node/src/node.cc in Ihrem Texteditor erneut und beheben Sie den Fehler.

Sobald Sie es geschafft haben, diese neue modifizierte NodeJS-Version zu kompilieren und zu installieren, können Sie überprüfen, ob Ihre Änderungen tatsächlich in die Software integriert wurden:

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

Herzliche Glückwünsche! Sie haben Ihre erste Änderung an einem Open-Source-Programm vorgenommen!

D. Lassen Sie die Shell unsere benutzerdefinierte Build-Software finden

Möglicherweise haben Sie bis jetzt bemerkt, dass ich meine neu kompilierte NodeJS-Software immer durch Angabe des absoluten Pfads zur Binärdatei gestartet habe.

 /opt/node/bin/node 

Es klappt. Aber das ist gelinde gesagt ärgerlich. Es gibt zwei Möglichkeiten, dies zu beheben. Um sie jedoch zu verstehen, müssen Sie zuerst wissen, dass Ihre Shell die ausführbaren Dateien findet, indem Sie sie nur in den Verzeichnissen suchen, die in der Umgebungsvariablen PATH angegeben sind.

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

Wenn Sie auf diesem Debian-System kein Verzeichnis als Teil eines Befehlsnamens explizit angeben, sucht die Shell zuerst nach diesen ausführbaren Programmen in /usr/local/bin, und wenn sie nicht in /usr/bin wird Wenn es nicht in /bin wird, wenn es nicht in /usr/local/games wird, wenn es nicht in /usr/games, wenn es nicht gefunden wird, meldet die Shell den Fehler "Befehl nicht gefunden" .

Vorausgesetzt, wir haben zwei Möglichkeiten, einen Befehl für die Shell zugänglich zu machen: indem wir ihn einem der bereits konfigurierten PATH Verzeichnisse hinzufügen. Oder indem Sie das Verzeichnis mit unserer ausführbaren Datei zum PATH hinzufügen.

Hinzufügen eines Links aus / usr / local / bin

Das Kopieren der ausführbaren Knoten-Binärdatei von /opt/node/bin nach /usr/local/bin wäre eine schlechte Idee, da das ausführbare Programm auf diese Weise die anderen erforderlichen Komponenten von /opt/node/ nicht mehr finden kann /opt/node/ (Es ist üblich, dass eine Software ihre Ressourcendateien relativ zu ihrem eigenen Speicherort findet.)

Die traditionelle Methode hierfür ist die Verwendung eines symbolischen Links:

 [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) 

Dies ist eine einfache und effektive Lösung, insbesondere wenn ein Softwarepaket aus nur wenigen bekannten ausführbaren Programmen besteht, da Sie für jeden vom Benutzer aufrufbaren Befehl eine symbolische Verknüpfung erstellen müssen. Wenn Sie beispielsweise mit NodeJS vertraut sind, kennen Sie die Npm-Begleitanwendung, die ich auch aus /usr/local/bin verknüpfen sollte. Aber ich lasse dir das als Übung.

Ändern des PFADS

Wenn Sie die vorstehende Lösung ausprobiert haben, entfernen Sie zunächst die zuvor erstellte knotensymbolische Verknüpfung, um von einem eindeutigen Status aus zu beginnen:

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

Und jetzt ist hier der Zauberbefehl, um deinen PATH zu ändern:

 [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 

Einfach gesagt, ich habe den Inhalt der Umgebungsvariablen PATH durch den vorherigen Inhalt ersetzt, jedoch mit dem Präfix /opt/node/bin . Wie Sie sich jetzt vorstellen können, sucht die Shell zuerst im Verzeichnis /opt/node/bin nach ausführbaren Programmen. Wir können das mit dem folgenden Befehl bestätigen:

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

Während die "Link" -Lösung permanent ist, sobald Sie den symbolischen Link in /usr/local/bin, wird die PATH Änderung nur in der aktuellen Shell wirksam. Ich lasse Sie einige Nachforschungen anstellen, um zu wissen, wie Sie Änderungen an den PATH Permanenten vornehmen können. Ein Hinweis, es hat mit Ihrem „Profil“ zu tun. Wenn Sie die Lösung finden, zögern Sie nicht, diese mit den anderen Lesern zu teilen, indem Sie den Kommentarbereich unten verwenden!

E. So entfernen Sie die neu installierte Software aus dem Quellcode

Da sich unsere benutzerdefiniert kompilierte NodeJS-Software vollständig im Verzeichnis /opt/node-v8.1.1, ist das Entfernen dieser Software nur mit dem Befehl rm :

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

ACHTUNG: sudo und rm -rf sind ein gefährlicher Cocktail! Überprüfen Sie Ihren Befehl immer zweimal, bevor Sie die Eingabetaste drücken. Sie werden keine Bestätigungsnachricht erhalten und kein Wiederherstellen, wenn Sie das falsche Verzeichnis entfernen ...

Wenn Sie dann Ihren PATH geändert haben, müssen Sie diese Änderungen rückgängig machen. Was überhaupt nicht kompliziert ist.

Und wenn Sie Links aus /usr/local/bin haben, müssen Sie diese alle entfernen:

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

Warten? Wo war die Abhängigkeitshölle?

Wenn Sie sich abschließend mit dem Kompilieren Ihrer eigenen benutzerdefinierten Software befassen, haben Sie möglicherweise von der Hölle der Abhängigkeiten gehört. Dies ist ein Spitzname für die ärgerliche Situation, in der Sie, bevor Sie eine Software erfolgreich kompilieren können, zunächst eine vorausgesetzte Bibliothek kompilieren müssen, die wiederum eine andere Bibliothek erfordert, die wiederum möglicherweise nicht mit einer anderen Software kompatibel ist, die Sie bereits haben Eingerichtet.

Teil der Aufgabe der Paketbetreuer Ihrer Distribution ist es, diese Abhängigkeitsschwierigkeiten tatsächlich zu beheben und sicherzustellen, dass die verschiedenen Softwareprogramme Ihres Systems kompatible Bibliotheken verwenden und in der richtigen Reihenfolge installiert werden.

In diesem Artikel habe ich absichtlich NodeJS installiert, da es praktisch keine Abhängigkeiten hat. Ich sagte "virtuell", weil es tatsächlich Abhängigkeiten gibt. Der Quellcode dieser Abhängigkeiten befindet sich jedoch im node/deps des Projekts (im Unterverzeichnis node/deps ), sodass Sie sie nicht vorher manuell herunterladen und installieren müssen.

Wenn Sie jedoch mehr über dieses Problem erfahren möchten und wissen möchten, wie Sie damit umgehen, teilen Sie mir dies im Kommentarbereich unten mit: Das wäre ein großartiges Thema für einen fortgeschritteneren Artikel!

Empfohlen

So installieren Sie Google Chrome App Launcher unter Linux
2019
12 Einplatinencomputer: Alternative zu Raspberry Pi
2019
Schlechte Nachrichten! Windows 10 wird bald einen echten Linux-Kernel haben
2019