Ubuntu WSLインスタンスにlibuvをインストールしたいので、特にバージョン1.45.0以降が必要です。
私の理解(fromこのチュートリアル記事)インストールできるパッケージのバージョンを確認するコマンドは次のとおりですapt list | grep
。
$ apt list | grep libuv
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libuv1-dev/jammy,now 1.43.0-1 amd64 [installed]
libuv1/jammy,now 1.43.0-1 amd64 [installed,automatic]
libuvc-dev/jammy 0.0.6-1.1 amd64
libuvc-doc/jammy 0.0.6-1.1 all
libuvc0/jammy 0.0.6-1.1 amd64
apt-get
... 1.43.0-1のみインストールでき、すでにインストールされていると思います。
しかし、libuv GitHubサイト最新バージョンが利用可能であることを示します。
Ubuntuインスタンスでlibuv v1.45.0(またはそれ以上)をどのように使用しますかapt-get
?
私が緊急に必要とするのはlibuvに限定されていますが、実際にはUnix / Linuxエコシステムの一般的な側面、つまりドライバ/パッケージ/などの関係が何であるかを理解したいと思います。たとえば、GitHubページに従って「公開」されているように見えるものと、パッケージマネージャに「利用可能」と思われるものは何ですかapt-get
?パッケージマネージャが提供していない最新バージョンのパッケージが必要な場合は、どうすればよいですか?ソースコードをダウンロードしてローカルでコンパイルする必要がありますか?
修正する:1.45.0が必要なのはなぜですか?つまり、パッケージマネージャが提供するよりも高度なバージョンが必要なのはなぜですか?
私のLinuxボックスは、ホストコンピュータにコンパイルする必要がある開発環境です(つまり、この質問の文脈では、クロスコンパイルは無視できます)。私が書いたものではなくコンパイルする必要があるアプリケーションは、uv_timespec64_t
libuv v1.45.0で紹介されているように見えるthisに依存します。この子のマージ/違い)。
したがって、これがこの質問の前提です。 Linuxディストリビューションのパッケージマネージャが提供するよりも、最新バージョンのlibuv機能に依存するアプリケーションを(ホストシステムに)コンパイルする必要があります。
更新:この質問には関連する次の質問があります。Linuxディストリビューションごとにパッケージ形式(およびパッケージマネージャ)が異なるのはなぜですか?
答え1
茎と木
@TechLoomがこれに関するあなたの質問に答えている間、libuv
Linuxエコシステムに関するあなたの質問に答えます。私たちから始めましょう
新しいブラウザタブで開き、5つのデフォルトトランクがあることを確認してください。
- 余裕ソフトウェア
- ダーバン
- Red Hatはエンタープライズ指向であり、無料版はFedoraと呼ばれています。
- エノクは短い人生を送り、後でGentooになりました。
- アーチ
各ブランチとすべてのサブブランチは、デフォルトで使用されているパッケージ管理システムによって定義されます。
- デフォルトのSlackwareはzip / unzip / tarを使用します。パッケージを解凍して手動でコンパイル
- Debian(Ubuntuがサブブランドである)は、APT(私の記憶が正しい場合はAdvanced Packaging Tool)を使用しています。
- Red Hat / FedoraはRPM - RPMパッケージマネージャを使用します。
- Enochとその子供たちはスクリプトを使ってすべてを最初からコンパイルします。 Slackwareを想像してみてください。ただし、自動化され構成可能です。
- アーチは長年にわたり良好な性能を発揮したハイブリッドです。ユーザーは完全にバイナリパッケージシステム、つまりDebianなどのパッケージ、Enochなどの完全にコンパイルされたシステム、またはその2つの組み合わせを持つことができます。
それでは、生態系がどのようにつながるかを見てみましょう。各パッケージマネージャは、指定されたパッケージツリー(ストアとも呼ばれる)にのみ接続するように構成されています。 Debianベースのシステムは、ファイルをダウンロードしてインストールできるAPTベースのツリーにリンクされています.deb
。これらの各パッケージマネージャにより、ユーザーはカスタムツリーをインストールできます。 UbuntuベースのシステムはこれをPersonal Package Archive(PPA)と呼びます。
リリースサイクル
パッケージマネージャに関係なく、すべてのディストリビューションにはリリースサイクルがあります。リリースサイクルは「ロックされたリポジトリ」と考えるか、ツリーのたとえ話を使用して「もはや成長しない健康的なツリー」と考えることができます。リポジトリには、特定のバージョンに属するパッケージのみが含まれます。通常、このバージョンでインストールされたパッケージは変更されず、まれな場合にのみ更新されます。つまり、重要なバグ修正がリリースされている場合(このバージョンではlibuv-1.45が見つかりません)、およびを見てjammy
いくつかあります。次のバージョンのコード名は次のとおりです。mantic
noble
パッケージがぶつかったのを見ました。(望むより新しいバージョンを更新次のような)。ブラウザやメールクライアントなどのソフトウェアは、通常、ストレージをcontrib
妨げない(貢献した)ストレージに公開されますmain
。 Debian という用語は貢献リポジトリと呼ばれているようですが、universe
かなり適切な表現です(空の下にあるすべてのユーザーソフトウェアをそこに置くことができます)。追加された各パッケージは、リポジトリのライブラリとツールに基づいてコンパイルmain
、パッケージ化、およびアップロードされます。universe
これは、ユーザーまたは会社が追加したソフトウェアの「ロックされたストレージ」の概念を模倣します。
Ubuntuの場合、リリースサイクルは通常1年に2回(マイナーバージョンアップデート[3番目のバージョン番号]がない限り4月に1回、10月に1回)発生します。あなたは見ることができますUbuntu配布リスト。許可される慣行は、管理者が更新するまで、そのバージョンで利用可能なパッケージのみを使用することです。
一部のディストリビューションでは、ローリングリリースモデル、特にソースコードベースのディストリビューションを使用します。。ソースコンパイルされたGentooボックスに更新コマンドを実行し、パッケージを再構築し、1時間後に同じ更新を実行し、同じパッケージを再更新することもできます。
私たちの友人や敵(好みに応じて)も、MicrosoftはWindows 10からリリースモデルを採用しています。現在のWindows 11バージョンは23H2バージョンで、2023年下半期発売予定だ。 Windows 10の最初のメジャーバージョンは1903で、これは2019年3月を意味します。マイクロソフトの「ツリー」は公に公開されていませんが、バグ修正とユーザーの要求に基づいた更新プログラムを将来のWindowsバージョンに統合するために使用されます。
バージョンロックが重要な理由
ロックの概念がなぜそれほど重要なのかを理解するには、BMW車を所有していると想像してください。 BMWは主に手作業で作られ、チューニングされています。 BMWと最初に通信することなく、2023年に購入するモデルに2025年モデルの機能Xを追加することにしたとします。
- 機能Xを有効にするために必要な部品をWebから購入します。
- 私たちはダッシュボードに部品を取り付けて電気システムに接続しましたが、機能Xを持つ部品には特別なコネクタが必要であることに気づきました。
- コネクタなしでFunction Xの部品を接続しようとしましたが、最終的に6つの車が損傷しました。
- 私たちはBMWに連絡して機能X接続を試みましたが、アップグレードよりも多くのダメージを与えたと言いました。 BMWは私達にコネクタを送り、認定メカニズムにすべてを組み立てるように言った。
私はそれをすべて1つにまとめるために最後の弾丸を太字でマークしました。上記の「アップグレード」では、BMWは「ロックされたリポジトリ」の管理者です。 BMWは、お問い合わせ時にほとんどの自動車のすべての部品を保持または入手できます。ツリーの外側に特別なコネクタは存在しません。同様に、ソフトウェアがリポジトリにある場合にのみ、Ubuntuバージョン(この物語の車)にソフトウェアを追加またはアップグレードできます。異なるバージョンのリポジトリを混在させると、完全な損傷が発生する可能性があります。 Feature Xを追加するか、以前のバージョンからアップグレードする必要がある場合、ソフトウェアはバックポートmain
、その特定のバージョン(マシンデバイス)のリポジトリにgetが追加され、そのバージョンは期待どおりに実行され続けました(自動車が修正されました)。
新しいバージョンを更新
バージョンのアップグレード(たとえば、1.43から1.45へ)は通常、次のように実行されます。
- 管理者が新しいバージョンを確認するか、ユーザーが管理者にバージョン更新要求を送信します。
- 要求されたビルドは、信頼性テストのためにベータビルドに送信されます。 Ubuntuではこれを今後のリリースといいます。
- パッケージはテストされ、撤回または承認され、将来のバージョンが最新バージョンになるとリリースされます。
LTSバージョン
信頼性が必要なユーザーには、一部のディストリビューションでは長期サービスリリースの概念を使用しています。これは通常、Webサーバー、ファイアウォール、またはドメインコントローラなどのビジネス上の重要なアプリケーションがある領域に優先されます。
答え2
githubページからソースコードをダウンロードできます。
https://github.com/libuv/libuv/releases
次にソースファイルを抽出し、プログラムをコンパイルしてインストールします。すべてのステップはgithubページにあります。
https://github.com/libuv/libuv#build-instructions
$ sh autogen.sh
$ ./configure
$ make
$ make check
$ make install
別のオプションは、プロジェクトのリポジトリを持っている人がいることを確認することです。その後、「add-apt-repository」を使用し、必要に応じてaptを使用できます。