主なパッケージマネージャは（特別な順序なしで）apt、yum、およびpacmanのようです。しかし、最終的に違いは何ですか？私の理解は、各ディストリビューションが他のディストリビューションよりも好まれているようですが、すべてのディストリビューションでこれらのいずれかを使用できることです。
だから私の質問は：主なパッケージマネージャ間の主な違いは何ですか？なぜどちらかを考慮する必要がありますか？
答え1
さて、基本的に処理するパケットタイプ（apt - deb; yum - rpm; pacman - tar.gz）についてですが、これらのパッケージングシステム自体は少し異なります...そして依存関係を処理する方法はどうですか（非常に重要） ...もちろん - 彼らが提供するオプションとインストールされているパッケージに関するデータを表示する方法...これが主な違いの一部であると言いたいのですが...
答え2
あなたが参照するパッケージマネージャは、実際には基本パッケージングシステムのフロントエンドのオプションです。たとえば、yumはRPMのフロントエンドですが、他のフロントエンド（smart、zypper、apt4rpmなど）も存在します。同様に、DPKGベースのシステムには、デフォルトで2〜3つのパッケージマネージャ（Synaptic、Aptitude、apt-get、dselectなど）があります。私はそこにコメントするほどPacmanについて十分に知りません。
フロントエンドは実際にはあまり興味深いものではありません。特定のレベルの依存関係の解決に対処する必要がありますが、パッケージ管理の本当に「難しい」部分は、デフォルトのパッケージ形式に由来します。
繰り返しますが、Pacmanについては言及できませんが、RPMとDPKGの間では、RPMはより困難な作業を行います。 RPMパッケージで非常に複雑な関係を定義でき、パーサーはこれらの関係を何らかの形で処理する必要があり、パッケージ定義では次の問題が発生する可能性があります。痛み。依存関係情報に関する限り、DPKGはパッケージ名とバージョンの2つの項目のみを定義できるため、より単純な形式ですが、RPMを使用すると、依存関係のシンボルバージョン管理などの複雑な操作を実行できます。
したがって、あなたの質問に答えると、単一の形式の管理者の選択は個人的な好みに依存します（私は主に能力を使用します）。型間の選択は、コントロールをどれだけ詳細にしたいかによって異なります（そして皮肉なことに、コントロールがパッケージングに導入する複雑さの程度）。
答え3
パッケージマネージャは、2つの主要なカテゴリに分けることができます。
バイナリパッケージマネージャ：ソフトウェアは一部のリモートシステムに構築されており、コンパイルされた結果のみを取得できます。最も広く使用されている（唯一の？）形式はdeb（apt）とrpm（yum）です。
ソースパッケージマネージャ：ソフトウェアコードソースコードを直接取得し、ローカルでコンパイルします。一部のソースパッケージマネージャは、BSD、Mac Ports、Homebrew、pip（Python）、gem（Ruby）などのEmerge、pacman、yaourt、slackpkgです。
バイナリパッケージの主な利点は次のとおりです。設置時間が大幅に短縮されます。インターネット帯域幅が十分に高い場合。再現性も良くなりましたパッケージのバージョンは常に1つのバイナリに固有です。
弱点はパッケージサイズ(ソースコードより数倍大きい)システム剛性：Windowsとは異なり、Linuxのバイナリはハードコーディングされたパスに含まれることが多く、再配置可能なバイナリ（移動可能なバイナリ）を作成することは困難です。つまり、バイナリパッケージ管理は通常/usrでのみ機能します。
ソースコードとバイナリの違いを教えてください。Debian アーカイブ現在のソースはわずか1Tbを超えていますが、72Gbに過ぎません！ amd64のような1つのアーキテクチャは、約95 + 92 = 187 Gb（2.5（1）より大きい）です。
バイナリパッケージのもう一つの問題は固定コンパイルフラグ：一部のオプション機能はシステムパッケージで無効にすることができ、最新のCPU拡張は互換性のために無効にすることができます。
議論の余地がある点の1つは、バイナリパッケージマネージャが以下を提供する傾向があることです。旧バージョン。実際、各リリースの直後に各パッケージに最新のアップデートを提供するのは、ほとんどの場合、ソースコードパッケージマネージャです。しかし、バイナリパッケージはリポジトリに到達する前に広範なテストを受ける傾向があります。持つすべてのアーキテクチャで正常にコンパイルされます！ ）。
選択を支援するための一般的なパターンは、構成プロセスに時間を費やしたくないサーバーやボックスにバイナリパッケージマネージャを使用することです。ソースパッケージマネージャは、「上級ユーザー」が使用する開発システムと、最先端のライブラリが必要な場所でより頻繁に使用される傾向があります。
（1）95Gb + 92Gbは、amd64パッケージとアーキテクチャに依存しないファイル（マルチメディアリソース、フォント、ドキュメントなど）である「すべての」パッケージの合計です。