質問: 主要なパッケージマネージャーはどのように異なりますか? 主要なパッケージマネージャーは(順不同で)apt、yum、pacmanのようです。しかし、それがそれになると、違いは何ですか?私の理解では、どのディストリビューションもどちらか一方を優先しているように見えますが、どのディストリビューションでもそれらのいずれかを使用できます。だから、私の質問は次のとおりです。主要なパッケージマネージャー間の主な違いは何ですか?なぜ私は一方を他方よりも考慮する必要がありますか?
回答: パッケージマネージャーは、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パッケージと、アーキテクチャに依存しないファイル(マルチメディアリソース、フォント、ドキュメントなど)である「すべての」パッケージの合計です。