Archは、オペレーティングシステム（パーティション、ファイルシステム、x86）のブートプロセス、ブートローダ、MBR / UEFIの内部、および周辺のさまざまな高度な移動部分の概要を取得するための簡単な開始点を探している新しいLinuxユーザーのための優れたディストリビューションです。 、ハードウェアドライバ、カーネル、カーネルスペースとユーザースペース、デスクトップ環境、インターネットプロトコル、カーネルモジュール、ptracing、仮想化など）。
私はABSとパックマンが好きです。理由は何でも（サポートの中断をサポートするプロジェクトを構築したり、私のコンピュータだけなので、BではなくAをインストールしたいです！）特定のバージョン一部のソフトウェア（SDK、ドライバ、または奇妙なライブラリ）。 2つのオプションがあります。
- あなたは幸運ですインターネットの何人かのランダムな人々このパッケージバージョンはAURで利用可能です。
- オープンソースプロジェクトの場合は、PKGBUILDを使用してソースからビルドできます。
最初の問題は不一致、つまり信頼問題です。 2番目の問題の問題は、プロジェクトとその膨大な依存関係を継続的にコンパイルして再コンパイルするために無駄にする追加のサイクルがないことです。
「最新バージョンしか入手できません」が機能で何度も繰り返されるのを見ますが、実際には「最新」が良くなく、しばしば必要なものではありません。私はこれがパッケージマネージャの作業量を減らすと思います（難しいことです）。それはすべてです。これはpacman / PKGBUILD / ABSの基本的な欠陥ですか、それともArchリポジトリのオプションですか？
私が言うものではないことに注意してください。以前にインストールされたパッケージをダウングレード（どの可能キャッシュから）、私が言うことは特定バージョンのパッケージのインストール。とても簡単です。
Arch（カスタムストレージなし、ディスクイメージなし）を使用して再現可能な環境を作成しようとするのは非常に面倒です。実際に作業を必要とするアーチユーザーは、この問題をどのように解決できますか？別のディストリビューションに切り替えるのは唯一の実用的なオプションですか？
答え1
すべてのアイテムを常に再構築したい場合を除き、特定のバージョンを必要とするのはローリングリリースリリースのユースケースとはほとんど逆です。
だから私は次のことが心配です。
- 特定のバージョン、好ましくはディストリビューションと互換性のあるパッケージで必要なソフトウェアを構築する方法を学ぶ必要があります。
- パッケージと同様に、それに依存するすべてのソフトウェアを構築する方法を学ぶ必要があります。
- 依存関係を更新するたびに、上記のすべてのエントリを直接再構築する必要があります。
たとえば、このバージョンではlibgnuradio-3.10.7.1を使用したいとします。これはspdlog、libboost、fftw、Qt5、libstdc++、libc…によって異なります。あなたのソフトウェアでgr-osmosdrとgqrxを使いたいです。どちらもそれに依存します。
必要なバージョンでGNU Radioをビルドしてインストールしたら、libgnuradio-3.10.7.1を入手してください。これで、Linuxディストリビューションでspdlogが更新されました。 spdlog が更新されたので、libgnuradio を再構築して作業を続行できます。
libgnuradioからエクスポートされたシンボルはspdlogのシンボル/タイプによって異なりますので、libgnuradio、gqrx、およびgr-osmosdrに接続されているすべてのソフトウェアも再構築する必要があります。
これはArch Linuxだけではなく、ライブラリがどのように機能するかです。 ABIと互換性のないすべてのアップデートはリンクされているすべての項目を破損し、ライブラリの作成者が明示的な注意を払い、これを防ぐための措置を講じない限り、この動作は転移的です。
しかし、アーチの特徴はいローリングリリースリリースなので、ABIレベルだけでなくAPIレベルでも破壊的な方法で依存関係を更新する速度に制限はありません。いつでもlibgnuradio-3.10.7.1をビルドできない可能性があります。もはやlibboostで使用されるので、ヘッダーは消えます。アーチは私がこれまで使ってきたディストリビューションのうち、この機能をサポートしていない唯一のディストリビューションだという点を付け加えたいと思います。ケア依存関係バージョンについて - 他のディストリビューションとは異なり、spdlogをアップグレードするには、libgnuradioが以前のバージョンのspdlogを使用しているため、それらを削除する必要があることを知らせます。 Archでは、デフォルトでは、すべてのアップデートには完全なシステムアップデートが必要です。どのすべてが機能し続けるように更新されました。これはあなたのユースケースの最悪の場合の基準です！
したがって、特定のユースケースの場合、Archは希望のディストリビューションではありません。 APIを保証し、早期更新を得るためにABIに違反しないディストリビューションが必要です。
だから：
- 幸いなことに、インターネット上の誰かがAURでこのパッケージバージョンを提供しています。
- オープンソースプロジェクトの場合は、PKGBUILDを使用してソースからビルドできます。
これらのどれも、Arch Linuxで何かを更新するたびに完全な依存ツリーを再構築する必要があるという問題を解決することはできません。さらに、AURは間違いなく追加の信頼をもたらしません。その目的は次のとおりです。いいえArch Linux の正式に保守および承認される部分です。
1 このようなことが何度も起こりました。これが現代のC ++がある現在libboostを使用するのに非常に慎重な理由です。
答え2
より信頼性の高いディストリビューションでも、特定のパッケージバージョンが十分に古い場合はインストールできません。
ディストリビューションがまだ提供していない（以前の）特定のバージョンが本当に必要な場合は、最良のオプションは、その特定のバージョンを含むディストリビューションバージョンにコンテナを設定することです。その後、コンテナのソフトウェアバージョンを固定することができ、コンテナ内に隔離されているため、コンテナの古いソフトウェアによるセキュリティの脆弱性について（あまりにも）心配する必要はありません。
もちろん、より良い解決策は、問題のソフトウェアを現在のバージョンのツールとライブラリを使用するように調整するか、すでにこれを実行している最新バージョンのソフトウェアにアップグレードすることです。