it-mure.jp.net

主要なパッケージマネージャーはどのように異なりますか?

主要なパッケージマネージャーは(順不同で)apt、yum、pacmanのようです。しかし、それがそれになると、違いは何ですか?私の理解では、どのディストリビューションもどちらか一方を優先しているように見えますが、どのディストリビューションでもそれらのいずれかを使用できます。

だから、私の質問は次のとおりです。主要なパッケージマネージャー間の主な違いは何ですか?なぜ私は一方を他方よりも考慮する必要がありますか?

4
Thomas Owens

基本的には、処理するパケットの種類(apt --deb; yum --rpm; pacman --tar.gz)についてであり、これらのパッケージングシステム自体は少し異なります...次に、依存関係をどの程度うまく処理するかという問題があります(非常に重要です)...そしてもちろん-それらが提供するオプションと、インストールされているパッケージに関するデータをどのように提示できるか...これらは主な違いのいくつかだと思います...

2
pootzko

パッケージマネージャーは、2つの主要なカテゴリに分類できます。

  1. バイナリパッケージマネージャー:ソフトウェアは一部のリモートマシン上に構築されており、コンパイルの結果のみを取得します。最も人気のある(のみ?)フォーマットはdeb(apt)とrpm(yum)です。

  2. ソースパッケージマネージャー:ソフトウェアコードソースが直接取得され、コンパイルがローカルで実行されます。いくつかのソースパッケージマネージャーが登場し、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パッケージと、アーキテクチャに依存しないファイル(マルチメディアリソース、フォント、ドキュメントなど)である「すべての」パッケージの合計です。

1
Thomas Moulard

あなたが引用するパッケージマネージャーは、実際には、基盤となるパッケージシステムのフロントエンドの選択肢にすぎません。たとえば、yumはRPMのフロントエンドであり、他にも存在します(smart、zypper、apt4rpmなど)。同様に、平均的なDPKGベースのシステムには、デフォルトで2つまたは3つのパッケージマネージャー(Synaptic、Aptitude、apt-get、dselectなど)があります。パックマンについてコメントするのに十分な知識がありません。

フロントエンドは実際にはそれほど興味深いものではありません。処理する必要のある依存関係の解決はある程度ありますが、パッケージ管理の本当に「難しい」部分は、基盤となるパッケージ形式に由来します。

繰り返しになりますが、パックマンについてコメントすることはできませんが、RPMとDPKGの間では、より難しい仕事をしているのはRPMです-RPMパッケージで非常に複雑な関係を定義できます。これは、リゾルバーが何らかの方法で処理する必要があります。あなたのパッケージ定義は、将来的に悲惨を引き起こすかもしれません。 DPKGは、依存関係情報に関する限り、はるかに単純な形式です。定義できるのはパッケージ名とバージョンの2つだけですが、RPMを使用すると、依存関係のバージョン管理されたシンボルなどの複雑なことを実行できます。

したがって、あなたの質問に答えるために、単一のフォーマット内のマネージャー間の選択は個人的な好みのみです(私は主に適性を使用します)。フォーマット間の選択は、必要なコントロールの粒度(皮肉なことに、そのコントロールをパッケージに導入する複雑さ)の1つです。

1
directhex