ソースコードからソフトウェアをインストールし、後で削除する方法

簡単な説明：この詳細なガイドでは、Linuxでソースコードからプログラムをインストールする方法と、ソースコードからインストールされたソフトウェアを削除する方法について説明します。

Linuxディストリビューションの最大の強みの1つは、パッケージマネージャーと関連するソフトウェアリポジトリです。これらを使用すると、完全に自動化された方法で新しいソフトウェアをコンピューターにダウンロードしてインストールするために必要なすべてのツールとリソースを利用できます。

しかし、すべての努力にもかかわらず、パッケージメンテナはすべてのユースケースを処理することはできません。また、そこにあるすべてのソフトウェアをパッケージ化することもできません。そのため、新しいソフトウェアを自分でコンパイルしてインストールしなければならない状況がまだあります。私の場合、最も一般的な理由は、ソフトウェアをコンパイルする必要があるのは、非常に特定のバージョンを実行する必要がある場合、またはいくつかの凝ったコンパイルオプションを使用してソースコードを変更する必要がある場合です。

あなたのニーズが後者のカテゴリーに属する場合、あなたはすでに何をすべきかを知っている可能性があります。しかし、大多数のLinuxユーザーにとって、ソースコードからソフトウェアを初めてコンパイルしてインストールすることは、入会式のように見えるかもしれません。しかし、新しい可能性の世界と特権的なコミュニティの名声の場所に入るという約束があります。

[irpposts =” 13491″ name =”Ubuntuでソフトウェアをインストールおよび削除する方法”]

A。 Linuxでのソースコードからのソフトウェアのインストール

そして、それがまさに私たちがここで行うことです。この記事の目的のために、NodeJS8.1.1をシステムにインストールする必要があるとしましょう。そのバージョンは正確に。 Debianリポジトリから入手できないバージョン：

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

これで、パッケージマネージャーを使用してNodeJをUbuntuまたはDebianにインストールするのは非常に簡単です。しかし、ソースコードを介してそれを実行しましょう。

ステップ1：GitHubからソースコードを取得する

多くのオープンソースプロジェクトと同様に、NodeJSのソースはGitHubにあります：https：//github.com/nodejs/node

それでは、直接そこに行きましょう。

GitHub、git、または言及する価値のあるその他のバージョン管理システムに慣れていない場合は、リポジトリにソフトウェアの現在のソースと、そのソフトウェアに対して何年にもわたって行われたすべての変更の履歴が含まれています。最終的には、そのプロジェクト用に作成された最初の行までです。開発者にとって、その履歴を保持することには多くの利点があります。今日の私たちにとって、主なものは、任意の時点でのプロジェクトのソースを取得できるようになることです。より正確には、必要な8.1.1バージョンがリリースされたときのソースを取得できるようになります。それ以来多くの変更があったとしても。

GitHubでは、「ブランチ」ボタンを使用して、ソフトウェアの異なるバージョン間を移動できます。「ブランチ」と「タグ」は、Gitでは多少関連する概念です。基本的に、開発者は「ブランチ」と「タグ」を作成して、新機能の作業を開始したときやリリースを公開したときなど、プロジェクト履歴の重要なイベントを追跡します。ここでは詳細については説明しません。知っておく必要があるのは、タグ付きのバージョンを探していることだけです。「v8.1.1」

「v8.1.1」タグを選択すると、ページが更新されます。最も明らかな変更は、タグがURLの一部として表示されるようになったことです。さらに、ファイルの変更日も異なることに気付くでしょう。現在表示されているソースツリーは、v8.1.1タグが作成されたときに存在していたものです。ある意味では、gitのようなバージョン管理ツールをタイムトラベルマシンと考えることができ、プロジェクトの履歴を行ったり来たりすることができます。

この時点で、NodeJS8.1.1のソースをダウンロードできます。プロジェクトのZIPアーカイブをダウンロードすることを提案する大きな青いボタンを見逃すことはできません。私は、説明のためにコマンドラインからZIPをダウンロードして解凍します。ただし、GUIツールを使用したい場合は、代わりにそれを行うことを躊躇しないでください：

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

ZIPアーカイブのダウンロードはうまく機能します。ただし、「プロのように」やりたい場合は、gitを直接使用することをお勧めします。ソースをダウンロードするためのツール。それはまったく複雑ではありません—そしてそれはあなたがしばしば遭遇するツールとの素晴らしい最初の接触になるでしょう：

# 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 \
              https://github.com/nodejs/node
sh$ cd node/

ちなみに、問題がある場合は、この記事の最初の部分を一般的な紹介として考えてください。後で、一般的な問題のトラブルシューティングに役立つように、DebianベースおよびRedHatベースのディストリビューションについてより詳細に説明します。

とにかく、gitを使用してソースをダウンロードしたときはいつでもまたは、ZIPアーカイブとして、現在のディレクトリにまったく同じソースファイルがあるはずです：

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

ステップ2：プログラムのビルドシステムを理解する

私たちは通常「ソースのコンパイル」について話しますが、コンパイルはそのソースから動作するソフトウェアを作成するために必要なフェーズの1つにすぎません。ビルドシステムは、いくつかのコマンドを発行するだけでソフトウェアを完全にビルドするために、これらのさまざまなタスクを自動化および明確化するために使用される一連のツールとプラクティスです。

概念が単純な場合、現実はやや複雑になります。プロジェクトやプログラミング言語が異なれば、要件も異なる可能性があるためです。またはプログラマーの好みのため。またはサポートされているプラットフォーム。または歴史的な理由で。または…または..別のビルドシステムを選択または作成する理由のほぼ無限のリストがあります。言うまでもなく、さまざまなソリューションが使用されています。

NodeJSはGNUスタイルのビルドシステムを使用しています。これはオープンソースコミュニティで人気のある選択肢であり、もう一度、旅を始めるのに良い方法です。

ビルドシステムの作成と調整は非常に複雑な作業ですが、「エンドユーザー」にとって、GNUスタイルのビルドシステムは次の2つのツールを使用して作業を容易にします。configure およびmake 。

configure fileはプロジェクト固有のスクリプトであり、プロジェクトをビルドできることを確認するために、宛先のシステム構成と使用可能な機能をチェックし、最終的に現在のプラットフォームの特異性を処理します。

典型的なconfigureの重要な部分仕事はMakefileを構築することです。これは、プロジェクトを効果的にビルドするために必要な手順を含むファイルです。

make 一方、ツールは、Unixライクなシステムで利用できるPOSIXツールです。プロジェクト固有のMakefileを読み取りますプログラムをビルドしてインストールするために必要な操作を実行します。

ただし、Linuxの世界ではいつものように、特定のニーズに合わせてビルドをカスタマイズすることには、まだある程度の寛大さがあります。

./configure --help

configure -help コマンドは、利用可能なすべての構成オプションを表示します。繰り返しになりますが、これは非常にプロジェクト固有です。そして正直なところ、すべての構成オプションの意味を完全に理解する前に、プロジェクトを掘り下げる必要がある場合があります。

ただし、知っておく必要のある標準のGNU Autotoolsオプションが少なくとも1つあります。それは、--prefixです。オプション。これは、ファイルシステム階層とソフトウェアがインストールされる場所に関係しています。

[irpposts =” 14419” name =”プロユーザーになるための8つのVimのヒントとコツ”]

ステップ3：FHS

一般的なディストリビューションのLinuxファイルシステム階層は、ほとんどの場合、ファイルシステム階層標準（FHS）に準拠しています

その標準は、システムのさまざまなディレクトリの目的を説明しています：/usr 、/tmp 、/var など。

GNU Autotools（および他のほとんどのビルドシステム）を使用する場合、新しいソフトウェアのデフォルトのインストール場所は/usr/localになります。。 FSH によると、どちらが適切な選択です。「/ usr / local階層は、ソフトウェアをローカルにインストールするときにシステム管理者が使用するためのものですか？システムソフトウェアが更新されたときに上書きされないように安全である必要があります。ホストのグループ間で共有できるが、/usrにはないプログラムやデータに使用できます。」

/usr/local 階層はどういうわけかルートディレクトリを複製し、そこに/usr/local/binがあります。実行可能プログラムの場合、/usr/local/lib ライブラリの場合、/usr/local/share アーキテクチャに依存しないファイルなど。

/usr/localを使用する場合の唯一の問題カスタムソフトウェアインストールのツリーは、すべてのソフトウェアのファイルがそこに混在することです。特に、いくつかのソフトウェアをインストールした後は、/usr/local/binのどのファイルに正確に追跡するのが困難になります。および/usr/local/lib どのソフトウェアに属しています。ただし、システムに問題が発生することはありません。結局のところ、/usr/bin ほぼ同じ混乱です。ただし、手動でインストールしたソフトウェアを削除したい日には、それが問題になります。

その問題を解決するために、私は通常、/optにカスタムソフトウェアをインストールすることを好みます代わりにサブツリー。もう一度、FHSを引用するには：

_” / optは、アドオンアプリケーションソフトウェアパッケージのインストール用に予約されています。

/ optにインストールするパッケージは、静的ファイルを別の/ opt/または/opt/ ディレクトリツリーに配置する必要があります。ここで、はソフトウェアパッケージを説明する名前で、はプロバイダーのLANANA登録名。」_

したがって、/optのサブディレクトリを作成します特にカスタムNodeJSインストール用です。そして、いつかそのソフトウェアを削除したい場合は、単にそのディレクトリを削除する必要があります：

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.

makeの後に「ok」以外のものコマンドが完了したということは、ビルドプロセス中にエラーが発生したことを意味します。 -jのため、並列ビルドを実行しましたオプションの場合、ビルドシステムによって大量の出力が生成されるため、エラーメッセージを取得するのは必ずしも簡単ではありません。

問題が発生した場合は、makeを再起動してください、ただし-jなし今回はオプション。そして、エラーは出力の終わり近くに表示されるはずです：

sh$ make

最後に、コンパイルが終了したら、次のコマンドを実行して、ソフトウェアをその場所にインストールできます。

sh$ sudo make install

そしてそれをテストします：

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

B。ソースコードからのインストール中に問題が発生した場合はどうなりますか？

上で説明したのは、ほとんどの場合、十分に文書化されたプロジェクトの「ビルド手順」ページに表示されるものです。しかし、この記事の目標がソースから最初のソフトウェアをコンパイルできるようにすることであることを考えると、いくつかの一般的な問題を調査するために時間をかける価値があるかもしれません。そのため、手順全体をもう一度実行しますが、今回は最新の最小限のDebian9.0およびCentOS7.0システムから実行して、発生したエラーとその解決方法を確認します。

Debian9.0「ストレッチ」から

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

この問題は、診断と解決が非常に簡単です。 gitをインストールするだけですパッケージ：

[email protected]:~$ sudo apt-get install git

[email protected]:~$ git clone --depth 1 \
                             --branch v8.1.1 \
                             https://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

ここでは問題ありません。

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

明らかに、プロジェクトをコンパイルするには、コンパイラが必要です。 NodeJSはC++言語を使用して記述されているため、C++コンパイラが必要です。ここでは、その目的のためにGNUC++コンパイラである`g++`をインストールします。

[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

もう1つの不足しているツール。同じ症状。同じ解決策：

[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

成功！

注意：コンパイルの問題を診断する方法と、それらの問題を解決するための一般的な解決策を示すために、さまざまなツールを1つずつインストールしました。しかし、トピックに関する詳細情報を検索したり、他のチュートリアルを読んだりすると、ほとんどのディストリビューションには、ソフトウェアのコンパイルに使用される一般的なツールの一部またはすべてをインストールするための傘として機能する「メタパッケージ」があることがわかります。 Debianベースのシステムでは、おそらくその目的のためのbuild-essentialsパッケージに遭遇するでしょう。また、Red-Hatベースのディストリビューションでは、それが「開発ツール」になります。グループ。

CentOS7.0から

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

コマンドが見つかりません？ yumを使用してインストールするだけですパッケージマネージャー：

[[email protected] ~]$ sudo yum install git

[[email protected] ~]$ git clone --depth 1 \
                               --branch v8.1.1 \
                               https://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.

ご想像のとおり、NodeJSはC ++言語を使用して記述されていますが、私のシステムには対応するコンパイラがありません。救助にヤム。私は通常のCentOSユーザーではないため、実際にはインターネットでg++コンパイラを含むパッケージの正確な名前を検索する必要がありました。そのページに私を導きます：https：//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

成功。もう一度。

C。ソースコードからインストールされたソフトウェアに変更を加える

配布リポジトリで利用できない非常に特定のバージョンが必要な場合、またはバグを修正したり機能を追加したりするためにプログラムを変更したい場合は、ソースからソフトウェアをインストールできます。結局のところ、オープンソースとは変更を加えることです。そこで、この機会に、独自のソフトウェアをコンパイルできるようになった今、手元にあるパワーを味わってみましょう。

ここでは、NodeJSのソースに小さな変更を加えます。そして、変更がソフトウェアのコンパイル済みバージョンに組み込まれるかどうかを確認します。

ファイルnode/src/node.ccを開きますお気に入りのテキストエディタ（vim、nano、gedit、…）で。そして、そのコードの断片を見つけてみてください：

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

ファイルの3830行目あたりです。次に、printfを含む行を変更します代わりにそれに一致させる：

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

次に、ターミナルに戻ります。先に進む前に、そしてgitの背後にある力についての洞察を深めるために、適切なファイルを変更したかどうかを確認できます。

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

変更前と同じように、行の前に「-」（マイナス記号）が表示されます。そして、変更後の行の前に「+」（プラス記号）を付けます。

今度は、ソフトウェアを再コンパイルして再インストールします。

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

今回、失敗する可能性がある唯一の理由は、コードの変更中にタイプミスをしたことです。この場合は、node/src/node.ccを再度開きます。テキストエディタでファイルを作成し、間違いを修正してください。

その新しい変更されたNodeJSバージョンをコンパイルしてインストールすると、変更が実際にソフトウェアに組み込まれたかどうかを確認できます。

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

おめでとう！オープンソースプログラムに最初の変更を加えました！

D。シェルにカスタムビルドソフトウェアを見つけさせます

バイナリファイルへの絶対パスを指定することで、新しくコンパイルしたNodeJSソフトウェアを常に起動していることに気付いたかもしれません。

/opt/node/bin/node

できます。しかし、控えめに言っても、これは面倒です。これを修正するには、実際には2つの一般的な方法があります。

バイナリファイルへの絶対パスを指定するという厄介な問題を修正するには、実際には2つの一般的な方法があります。
ただし、それらを理解するには、最初に、シェルがPATH環境変数で指定されたディレクトリでのみ実行可能ファイルを検索することによって実行可能ファイルを見つけることを知っておく必要があります。

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

ここで、そのDebianシステムでは、コマンド名の一部としてディレクトリを明示的に指定しない場合、シェルは最初に/usr/local/binで実行可能プログラムを探します。、/usr/binに見つからない場合、/binに見つからない場合次に、/usr/local/gamesに見つからない場合次に、/usr/gamesに見つからない場合、その後、見つからない場合…シェルはエラーを報告します「コマンドが見つかりません」 。

そのため、コマンドをシェルにアクセスできるようにする方法は2つあります。それは、すでに構成されているPATHの1つにコマンドを追加することです。ディレクトリ。または、実行可能ファイルを含むディレクトリをPATHに追加します。

/ usr / local/binからのリンクの追加

コピー /opt/node/binから実行可能なノードバイナリ /usr/local/binへそうすることで、実行可能プログラムは/opt/node/に属する他の必要なコンポーネントを見つけることができなくなるので悪い考えです。（ソフトウェアが自身の場所を基準にしてリソースファイルを見つけることは一般的な方法です。）

したがって、これを行う従来の方法は、シンボリックリンクを使用することです。

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

これは、特にソフトウェアパッケージがいくつかのよく知られた実行可能プログラムで構成されている場合、シンプルで効果的なソリューションです。ユーザーが起動できるコマンドごとにシンボリックリンクを作成する必要があるためです。たとえば、NodeJSに精通している場合は、npmを知っています。コンパニオンアプリケーション/usr/local/binからシンボリックリンクする必要がありますそれも。しかし、私はそれを演習としてあなたに任せます。

パスの変更

まず、前述の解決策を試した場合は、以前に作成したノードのシンボリックリンクを削除して、クリア状態から開始します。

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

そして今、これがあなたのPATHを変更する魔法のコマンドです：

[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

簡単に言うと、PATHのコンテンツを置き換えました以前のコンテンツによる環境変数ですが、プレフィックスは/opt/node/bin 。したがって、今想像できるように、シェルは最初に/opt/node/binを調べます。実行可能プログラムのディレクトリ。 whichを使用して確認できますコマンド：

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

一方、「リンク」ソリューションは、/usr/local/binにシンボリックリンクを作成するとすぐに永続的になります、PATH 変更は、現在のシェルに対してのみ有効です。 PATHを変更する方法について調査することをお任せしますパーマネント。ヒントとして、それはあなたの「プロフィール」と関係があります。解決策を見つけたら、下のコメントセクションを使用して、他の読者と共有することを躊躇しないでください！

E。新しくインストールしたソフトウェアをソースコードから削除する方法

カスタムコンパイルされたNodeJSソフトウェアは完全に/opt/node-v8.1.1にあるためディレクトリの場合、そのソフトウェアを削除するには、rmコマンドを使用してそのディレクトリを削除するだけです。

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

注意： sudo およびrm -rf 危険なカクテルです！「Enter」キーを押す前に、必ずコマンドを2回確認してください。間違ったディレクトリを削除しても、確認メッセージは表示されず、削除を取り消すこともできません…

次に、PATHを変更した場合、これらの変更を元に戻す必要がありますが、これはまったく複雑ではありません。

また、/usr/local/binからリンクを作成した場合それらをすべて削除する必要があります：

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

待って？依存関係地獄はどこにありましたか？

最後のコメントとして、独自のカスタムソフトウェアのコンパイルについて読んだ場合、依存関係地獄について聞いたことがあるかもしれません。これは、ソフトウェアを正常にコンパイルする前に、まず前提条件のライブラリをコンパイルする必要があるという厄介な状況のニックネームです。次に、別のライブラリが必要になり、そのライブラリは、すでに使用している他のソフトウェアと互換性がない可能性があります。インストールされています。

ディストリビューションのパッケージメンテナの仕事の一部は、その依存関係地獄を実際に解決し、システムのさまざまなソフトウェアが互換性のあるライブラリを使用し、正しい順序でインストールされていることを確認することです。

この記事では、NodeJSには実質的に依存関係がないため、意図的にNodeJSをインストールすることを選択しました。私は「事実上」と言いました。実際、それは依存関係。ただし、これらの依存関係のソースコードは、プロジェクトのソースリポジトリ（node/deps）にあります。サブディレクトリ）なので、事前に手動でダウンロードしてインストールする必要はありません。

ただし、その問題について詳しく理解し、対処方法を学ぶことに興味がある場合は、以下のコメントセクションを使用してお知らせください。これは、より高度な記事のすばらしいトピックになります。