Linuxディストリビューションごとにパッケージ形式（およびパッケージマネージャ）が異なるのはなぜですか？

パッケージ管理は非常に複雑な問題であり、これを解決するための様々な試みがなされてきました。各試みは以前の試みを改善しようとしますが、完璧ではありません。

パッケージ管理システムとフォーマットが一緒に設計されているため、各パッケージ管理システムは独自のフォーマットを使用します。理論的には、すべてのシステムが使用できる統一された形式があるかもしれませんが、依存関係グラフの作成、パッチ管理、構成ファイルの内容と配置、パッケージ間のバージョン互換性など、パッケージ管理の他の側面も変更する必要があります。パッケージを交換できるように統合されました。

すべてのパッケージ管理システムは依存関係管理に異なるアプローチを取り、すべてのディストリビューションはパッケージバージョンの選択とパッチ管理に異なるアプローチをとるため、統合する方法はありません。

これらの選択により、Linuxディストリビューションが構成されます。これを統合することは、すべてのディストリビューションを1つにマージすることです。これがパッケージ管理システムがディストリビューションの鍵である理由です。ディストリビューションを決定する決定はここにあります。実際、これよりもよく説明できる方法はありません。https://xkcd.com/927/

移植可能なパッケージ形式を作成する試みがたくさんありました。 Appimageはその一つです。デプロイパッケージに（ほぼ）すべての依存関係を組み込んで動作するため、パッケージは非常に大きく、不要なメモリを使用します。

別のオプションはスナップです。これにより、オペレーティングシステムから依存関係を再び分離して独自に処理しようとするため、あるスナップパッケージが依存している別のスナップパッケージをドラッグして、オペレーティングシステムコンポーネントのバージョンを再複製できます。

最終移植可能な基本パッケージは、パッチ、構成、コンパイル、およびインストールが必要なソースコードファイルのtarballです。これには依存関係は含まれていないため、インストーラはコンパイルする前に依存関係を解決する必要があります。依存関係をリストする標準的な方法がないため、状況はさらに悪化し、一部のパッケージはlibcの内容までシステムで標準として使用できる項目について多くの前提があるため気にしません。

この問題を解決するより良い方法はありません。すべてのソリューションに問題があります。問題を解決するためのソリューションを作成すると、さまざまな問題が発生し、多くのソリューションは相互に排他的です。

簡単な答えは主な理由Linuxディストリビューションは以下のために存在するため分布一貫したパッケージセット。永久に同じバージョンに滞在したくないので、アップグレードする方法も必要です。不要なソフトウェアをインストールしたくないので、必要なパッケージを選択する方法が必要です。将来を予測できないため、後でパッケージをインストールまたは削除してこの選択を変更する方法が必要です。再利用はソフトウェアエンジニアリングの基本原則の1つであるため、パッケージは他のパッケージに依存しているため、これらの依存関係を処理する方法が必要です。

これらすべてがパッケージ管理システムの誕生につながりました。

したがって、誰かが新しいLinuxディストリビューションを作成した場合、これはおそらく既存のすべてのLinuxディストリビューションに問題があると思うという意味です。パッケージ管理はLinuxディストリビューションの基本であるため、彼らが同意しないものの1つがパッケージ管理システムである可能性が高くなります。

これは、「なぜ私たちは複数のパッケージ管理システムを持っているのか」という質問に実際に答えず、「なぜ私たちは複数のLinuxディストリビューションを持っているのか」に戻ります。

今あなたはいいえLinuxディストリビューションが複数ある理由について質問してください。ただし、なぜ複数のパッケージマネージャがあるのか​​疑問に思うべきではありません。

ところで、ここにはLinuxに関連するものはありません。ほとんどのBSDには独自のパッケージマネージャもあります。 Commercial Unicesにはパッケージマネージャがあります。

一体Unixだけに該当するわけでもありません。 Windowsにのみソフトウェアをインストールするには6つの方法があり、その中にはパッケージマネージャがあります。 MicrosoftはNuGetパッケージマネージャを作成しましたが、.NETでのみ機能したため、コミュニティはChocolateyパッケージマネージャを作成しました。また、MicrosoftインストーラにのみMSIパッケージを作成するために必要な約12のツールがあります。サードパーティでのみ可能ですが、Microsoft自体にもいくつかのツールがあります。

しかし、別の理由があります。パッケージ管理、特に依存性管理とても難しい問題は解決する必要がありますが、とても簡単なようです。（この質問は良い例です。）

この問題は、解決するのが非常に困難であるという事実は、ほとんどすべての人が問題が発生したことを直接経験したことを意味します。信じられないほど単純に見えるという事実は、それが間違っていることを直接経験したほとんどすべての人が「それは愚かなことだ、私はもっとうまくできる」と思うことを意味します。

そして、パン今、N+1パッケージ管理システムを持つようになりました。

編集

すべてのディストリビューションがこの「内部」を共有するので、ここから始めましょう。すべてのソフトウェアは、ディストリビューションの一部として選択される前にある時点でコンパイルされます。正しく推測したように、完全にコンパイルされたプログラムには、次のいずれかまたは両方を含めることができます。

• ライブラリ：通常、共有オブジェクトファイルまたはアーカイブとして保存されます。バラより.aファイルと.soファイルの違いは何ですか？
• ヘッダーファイル。バラよりGCCドキュメントのヘッダファイル
• 実行可能プログラムとも呼ばれるバイナリファイル

パッケージにコンパイル

繰り返しますが、すべてのディストリビューションにパッケージがあり、すべてのディストリビューションにパッケージマネージャがあります。混乱を引き起こす可能性があると思われる部分は次のとおりです。包装形式および包装内容は包装管理システムではない。すべてのディストリビューションのパッケージ管理システムは、3つの部分で構成されています。

1. パッケージ形式（たとえば、コンパイルされたセクションの項目が保存またはソートされる方法）
2. パッケージングツール - ＃1に従ってコンパイルされたプロジェクトの実行可能ファイル/バイナリをパッケージ化します。これでパッケージが作成されます。
3. パッケージマネージャ - #2のツールを繰り返し呼び出して、パッケージの実行可能ファイル/バイナリを操作します。操作とは、以下を含むことができる操作を意味します。
   • 設置/再インストール
   • 移動する
   • 構成ファイルの更新
   • インストールされているすべてのパッケージを更新

パッケージマネージャを作成する理由

パッケージマネージャー以前は、パッケージングツールを使用してパッケージをインストールすることが完全に許可されました。このようにパッケージをインストールするときに発生する問題は次のとおりです。

1. Debianにfoo.debパッケージをインストールして起動しました。dpkg -i foo.deb
2. 次のコマンドを使用してfoo.debを実行してみました。foo
3. 次のエラーメッセージでプログラムが突然終了します。プログラム foo に bar.so ファイルは必要ありません。終了します。
4. これで詰まって実行が必要なので、foo手順1〜3を繰り返します。bar.deb
5. もう一度試しましたが、別のエラーが発生しました。プログラムバーには静的ライブラリbaz.aが必要です。その後、プログラムが終了します。

パッケージマネージャへのパッケージ

今私はステップ6を下り、本当に怒っていますfoo。私のためにすべてを行うことができるプログラムがあれば本当に良いと思います。これがパッケージマネージャの主な仕事です。パッケージマネージャはメモリに依存関係グラフを描画し、必要なものとfooそうでないものをbar計算します。依存関係のないパッケージが見つかるまで計算を続け、逆方向に作業し、必要なパッケージがインストールされていることを確認します。パッケージがインストールされ、必要な設定が有効になると、チャートに表示され、次のパッケージが検索されます。要件を満たすために検索された次のパッケージを更新する必要がある場合は、パッケージストアを照会して更新版を追加します。そして、今追加したアップデートにも必要なので、ダイアグラムを再起動するか、新しいブランチを再描画する必要があります。barbaz

このプロセスは、パッケージがインストールまたは更新されるたびに繰り返されます。

命名の違い

技術的には、パッケージマネージャ間に違いはありません。各管理者は、自分がインストールされているシステムで以前に説明した機能をすばやく実行します。前述のように、FH規格は要件が満たされると非常に柔軟であるため、すべてのディストリビューションは一部のパッケージ関連項目を調整することを決定し、パッケージマネージャでこれを行います。コンセプトが提案された時は主にブランド認知のためのものでした。 Rは.rpmRed Hatを意味し、3文字の.deb拡張子はDebianの略語です。

独自のパッケージをコンパイルするのが危険な理由

リンクした質問から最新バージョンを探していますが、libuvそのバージョンはUbuntu Repoでは利用できませんjammy。利用できないため、新しいバージョンをコンパイルすることは唯一のオプションですが、最善のオプションではありません。

• ソフトウェアをコンパイルすると、パッケージマネージャはパッケージのコンパイル後にパッケージをインストールしないため、パッケージ管理システムはコンパイルした内容を管理できません。簡単に言うと、管理されていないソフトウェアをホストすることに加えて、管理されていないソフトウェアを管理する必要がある面倒が追加され、パッケージマネージャが提供する機能が失われます。たとえ1つのパッケージについてでも言います。
• コンパイルされたパッケージが保存されていることを確認してください。~へクライアントのウェブサイト。上記のように、管理されていないソフトウェアでホストオペレーティングシステムを汚染しないことは、常にホストオペレーティングシステムに最適です。
• これは、そのプログラムへのすべての呼び出しがローカルであることを意味します。/bin顧客に言及するときにホストに言及する間違いを犯さないでください。/bin