主要なパッケージマネージャーはどのように異なりますか？
主要なパッケージマネージャーは（順不同で）apt、yum、pacmanのようです。しかし、それがそれになると、違いは何ですか？私の理解では、どのディストリビューションもどちらか一方を優先しているように見えますが、どのディストリビューションでもそれらのいずれかを使用できます。
だから、私の質問は次のとおりです。主要なパッケージマネージャー間の主な違いは何ですか？なぜ私は一方を他方よりも考慮する必要がありますか？
基本的には、処理するパケットの種類（apt --deb; yum --rpm; pacman --tar.gz）についてであり、これらのパッケージングシステム自体は少し異なります...次に、依存関係をどの程度うまく処理するかという問題があります（非常に重要です）...そしてもちろん-それらが提供するオプションと、インストールされているパッケージに関するデータをどのように提示できるか...これらは主な違いのいくつかだと思います...
パッケージマネージャーは、2つの主要なカテゴリに分類できます。
バイナリパッケージマネージャー：ソフトウェアは一部のリモートマシン上に構築されており、コンパイルの結果のみを取得します。最も人気のある（のみ？）フォーマットはdeb（apt）とrpm（yum）です。
ソースパッケージマネージャー：ソフトウェアコードソースが直接取得され、コンパイルがローカルで実行されます。いくつかのソースパッケージマネージャーが登場し、pacman、yaourt、slackpkg、BSDのpkgng、Mac Ports、Homebrew、pip（Python）、gem（Ruby）などがあります。
バイナリパッケージの主な利点は、インターネットの帯域幅が十分に高い場合、インストール時間が大幅に短縮されることです。 再現性も優れていますパッケージの1つのバージョンは、常に1つのバイナリにのみ対応します。
欠点は、パッケージサイズ（ソースコードの数倍）とシステムの剛性：Windowsとは異なり、Linux上のバイナリは通常、ハードコードされたパスを埋め込み、再配置可能なバイナリ（移動可能なバイナリ）を生成するのは困難です。つまりバイナリパッケージは通常/ usrでのみ機能します。
ソースとバイナリの違いを理解するために、 Debianアーカイブ は現在1Tbを少し超えていますが、ソースでは72Gbしかありません！ 1つのアーキテクチャ、たとえばAMD64は、約95 + 92 = 187Gb（2.5大きい（1））です。
バイナリパッケージのもう1つの問題は、修正されたコンパイルフラグです。システムパッケージで一部のオプション機能が無効になっている場合があり、互換性のために一部の最新のCPU拡張機能も無効になっている場合があります。理由...
議論の余地のある点は、バイナリパッケージマネージャーが古いリリースを提供する傾向です。実際、主にソースパッケージマネージャーは、各リリースの直後にすべてのパッケージの最新の更新を提供しています。ただし、バイナリパッケージは、リポジトリに到達する前に広範囲にテストされる傾向があります（結局のところ、すべてのアーキテクチャで正常にコンパイルできるように持っている）。
選択しやすいように、一般的なパターンは、構成プロセスに多くの時間を費やしたくないサーバーとボックスにバイナリパッケージマネージャーを使用することです。 「パワーユーザー」が使用する開発マシンで、最先端のライブラリが必要な場合、ソースパッケージマネージャーがより頻繁に使用される傾向があります。
（1）95Gb + 92Gbは、AMD64パッケージと、アーキテクチャに依存しないファイル（マルチメディアリソース、フォント、ドキュメントなど）である「すべての」パッケージの合計です。
あなたが引用するパッケージマネージャーは、実際には、基盤となるパッケージシステムのフロントエンドの選択肢にすぎません。たとえば、yumはRPMのフロントエンドであり、他にも存在します（smart、zypper、apt4rpmなど）。同様に、平均的なDPKGベースのシステムには、デフォルトで2つまたは3つのパッケージマネージャー（Synaptic、Aptitude、apt-get、dselectなど）があります。パックマンについてコメントするのに十分な知識がありません。
フロントエンドは実際にはそれほど興味深いものではありません。処理する必要のある依存関係の解決はある程度ありますが、パッケージ管理の本当に「難しい」部分は、基盤となるパッケージ形式に由来します。
繰り返しになりますが、パックマンについてコメントすることはできませんが、RPMとDPKGの間では、より難しい仕事をしているのはRPMです-RPMパッケージで非常に複雑な関係を定義できます。これは、リゾルバーが何らかの方法で処理する必要があります。あなたのパッケージ定義は、将来的に悲惨を引き起こすかもしれません。 DPKGは、依存関係情報に関する限り、はるかに単純な形式です。定義できるのはパッケージ名とバージョンの2つだけですが、RPMを使用すると、依存関係のバージョン管理されたシンボルなどの複雑なことを実行できます。
したがって、あなたの質問に答えるために、単一のフォーマット内のマネージャー間の選択は個人的な好みのみです（私は主に適性を使用します）。フォーマット間の選択は、必要なコントロールの粒度（皮肉なことに、そのコントロールをパッケージに導入する複雑さ）の1つです。