ソースコードからソフトウェアをインストールする方法…そしてその後それを削除する

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

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

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

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

A. Linuxのソースコードからソフトウェアをインストールする

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

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 

さて、あなたがパッケージマネージャを使ってインストールすれば、UbuntuやDebianにNodeJをインストールするのはとても簡単です。 しかし、それをソースコードでやりましょう。

ステップ1:GitHubからソースコードを入手する

多くのオープンソースプロジェクトのように、NodeJSのソースはGitHubで見つけることができます://github.com/nodejs/node

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

GitHubに慣れていないのであれば、gitやその他のバージョン管理システムには、そのソフトウェアの現在のソースと、そのソフトウェアに対するこれまでのすべての変更の履歴が含まれています。 最終的にそのプロジェクトのために書かれた一番最初の行まで。 開発者にとって、その履歴を維持することには多くの利点があります。 今日の私たちにとって、主なものは、ある時点でのプロジェクトのソースを入手できるということです。 もっと正確に言えば、私が欲しい8.1.1バージョンがリリースされたときのようにソースを入手することができます。 それ以来多くの修正があったとしても。

GitHubでは、「分岐」ボタンを使ってソフトウェアの異なるバージョン間を移動できます。 “ Branch”と“ tags”はGitではやや関連した概念です。 基本的に、開発者は、新機能の開発を開始するときやリリースを発行するときなど、プロジェクト履歴内の重要なイベントを追跡するために「ブランチ」と「タグ」を作成します。 私はここで詳細に入りません、あなたが知る必要があるのは私が「v8.1.1」とタグを付けられたバージョンを探しているということだけです

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

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

 wget //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 \ //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スタイルのビルドシステムは、 configuremake 2つのツールを使うことから再開しconfigure

configureファイルは、プロジェクトが確実にビルドできるように、最終的に現在のプラットフォームの特性を処理するために、インストール先のシステム設定と利用可能な機能をチェックするプロジェクト固有のスクリプトです。

典型的なconfigureジョブの重要な部分はMakefileを構築することです。 それはプロジェクトを効果的に構築するために必要な指示を含むファイルです。

一方、 makeツールは、あらゆるUnixライクシステムで利用可能なPOSIXツールです。 それはプロジェクト特有のMakefileを読み、あなたのプログラムを構築しインストールするのに必要な操作を実行します。

しかし、Linuxの世界ではいつもそうであるように、あなたはまだあなたの特定のニーズのためにビルドをカスタマイズするためにいくらかの待ち時間があります。

 ./configure --help 

configure -helpコマンドは、利用可能なすべての設定オプションを表示します。 繰り返しますが、これはプロジェクト固有のものです。 そして正直に言うと、すべてのconfigureオプションの意味を完全に理解する前に、プロジェクトを詳しく調べる必要がある場合があります。

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

ステップ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サブツリーにカスタムソフトウェアをインストールすることを好み/opt 。 もう一度、FHSを引用します:

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

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

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

 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再起動しmake 。ただし、 -jオプションは指定しません。 そして、エラーは出力の終わり近くに現れるはずです。

 sh$ make 

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

 sh$ sudo make install 

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

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

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

私が上で説明したのは、よく文書化されたプロジェクトの「構築手順」ページで見ることができるもののほとんどです。 しかし、この記事の目的は、最初のソフトウェアをソースからコンパイルできるようにすることなので、いくつかの一般的な問題を調査するには時間がかかる可能性があります。 それで、私はもう一度全手順をやりますが、今回は新鮮で最小限のDebian 9.0とCentOS 7.0システムからです。 それで、あなたは私が遭遇したエラーと私がそれらをどのように解決したかを見ることができます。

Debian 9.0“ Stretch”から

 [email protected]:~$ git clone --depth 1 \ --branch v8.1.1 \ //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 \ //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 ++コンパイラが必要です。 ここでは、その目的のためのGNU C ++コンパイラである `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 

もう一つ欠けている道具。 同じ症状です。 同じ解決策:

 [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 

成功!

注意してください:私はコンパイルの問題を診断する方法を示し、あなたにそれらの問題を解決するための典型的な解決方法を示すために一つずつ様々なツールをインストールしました。 しかし、そのトピックについてもっと調べたり、他のチュートリアルを読んだりすると、ほとんどのディストリビューションには、ソフトウェアのコンパイルに使用される一般的なツールの一部または全部をインストールするための包括的な「メタパッケージ」があります。 Debianベースのシステムでは、おそらくその目的のためにbuild-essentialsパッケージに遭遇するでしょう。 そしてRed-Hatベースのディストリビューションでは、それが「開発ツール」グループになります。

CentOS 7.0から

 [[email protected] ~]$ git clone --depth 1 \ --branch v8.1.1 \ //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 \ //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 ++コンパイラを含むパッケージの正確な名前を検索しなければなりませんでした。 そのページに私を導く://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のソースに小さな変更を加えます。 そして、私たちの変更がコンパイルされたバージョンのソフトウェアに組み込まれるかどうかを見ます。

好きなテキストエディタ(vim、nano、geditなど)でファイルnode/src/node.ccます。 そして、そのコードの断片を見つけてみてください。

  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つの一般的な方法があります。 しかし、それらを理解するには、最初にシェルが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に見つからなかった場合、見つからなかった場合、シェルはエラー"command not found"を報告します。

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

/ usr / local / binからリンクを追加する

/opt/node/binから/usr/local/binノードバイナリ実行可能ファイルをコピーするだけでは、実行可能プログラムが/opt/node/属する他の必要なコンポーネントを見つけることができなくなるため、悪い考えです。 /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に慣れているなら、あなたは私が/usr/local/binからシンボリックリンクするべきであるnpmコンパニオンアプリケーションを知っています。 しかし、練習としてあなたにそれをさせます。

PATHを修正する

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

 [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 。 そのため、今すぐ想像できるように、シェルは最初に/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) 

"link"ソリューションはシンボリックリンクを/usr/local/binに作成した直後には恒久的ですが、 PATH変更は現在のシェルに対してのみ有効です。 PATH恒久的に変更する方法を知るために、私はあなた自身でいくつかの研究をしましょう。 ヒントとして、それはあなたの「プロフィール」と関係があります。 解決策が見つかった場合は、以下のコメント欄を使用して、他の読者と共有してください。

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

私たちのカスタムコンパイルされたNodeJSソフトウェアは完全に/opt/node-v8.1.1ディレクトリにあるので、そのソフトウェアを削除することはそのディレクトリを削除するためにrmコマンドを使用することより多くの仕事ではありません:

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

注意: sudorm -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サブディレクトリ内)にあるので、手動でダウンロードしてインストールする必要はありません。

しかし、その問題についてもっと理解し、その対処方法を学びたいのであれば、以下のコメントセクションを使用してください。それはより高度な記事のための素晴らしいトピックになるでしょう!

推奨されます

バルセロナ市、Linuxとオープンソースを支持してマイクロソフトを結成
2019
LinuxユーザーがMeltdownと、CPUに影響を与えるspecterのバグについて知っておくべきこと
2019
注目に値するインシデント:Linuxカーネルメーリングリストのウェブサイトは何日にもわたってダウン
2019