deb対rpmの長所/短所は何ですか？
理由が何であれ、私は常にRPMベースのディストリビューション（Fedora、Centos、および現在のopenSUSE）を使用してきました。 debはrpmより優れていると言われているのをよく耳にしますが、理由を聞かれると、首尾一貫した答えを得ることができませんでした（通常、代わりに熱烈な怒りと大量の唾を飲みます）。
私はいくつかの歴史的な理由があるかもしれないと理解していますが、2つの異なるパッケージ化方法を使用する最新のディストリビューションの場合、誰かが一方と他方の技術的（またはその他）のメリットを与えることはできますか？
パッケージのメンテナ（Debianの専門用語では「開発者」になると思います）の主な違いは、パッケージのメタデータと付随するスクリプトを組み合わせる方法です。
RPMの世界では、すべてのパッケージ（管理するRPM）は~/rpmbuildのような場所にあります。その下には、spec-filesのSPECディレクトリ、ソースtarballのSOURCESディレクトリ、新しく作成されたRPMを配置するRPMSおよびSRPMSディレクトリがあります。 SRPMに、および現在関連しない他のいくつかのもの。
RPMの作成方法に関係するすべてはspec-fileにあります。適用されるパッチ、可能な前後のスクリプト、メタデータ、変更ログ、すべて。すべてのソースtarballとすべてのパッケージのすべてのパッチはSOURCESにあります。
個人的には、すべてがスペックファイルに含まれ、スペックファイルがソースtarballとは別のエンティティであるという事実が気に入っていますが、allSOURCESのソース。私見、SOURCESは非常にすばやく雑然としてきて、そこに何があるのか見失ってしまう傾向があります。ただし、意見は異なります。
RPMの場合、上流プロジェクトがリリースするものと同じexactと同じtarballをタイムスタンプまで使用することが重要です。通常、このルールには例外はありません。 Debianパッケージもアップストリームと同じtarballを必要としますが、Debianポリシーでは一部のtarballを再パッケージする必要があります（ありがとう、Umang）。
Debianパッケージは異なるアプローチを取ります。 （ここで間違いを許してください。私はRPMを使用している場合よりも、debを使用した場合の方がはるかに経験が浅いです。）Debianパッケージの開発ファイルは、パッケージごとのディレクトリに含まれています。
このアプローチについて私が（考えている）好きなのは、すべてが単一のディレクトリに含まれているという事実です。
Debianの世界では、（まだ）アップストリームではないパッケージでパッチを運ぶことは少し受け入れられています。 RPMの世界では（少なくともRed Hatの派生製品の中で）、これは嫌われます。 "FedoraProject：上流プロジェクトの近くにいる" を参照してください。
また、Debianには、パッケージ作成の大部分を自動化できる大量のスクリプトがあります。たとえば、setuptool'ed Pythonプログラムの-simple-パッケージを作成することは、いくつかのメタデータファイルを作成してdebuildを実行するのと同じくらい簡単です。 RPM形式のこのようなパッケージのスペックファイルはかなり短く、RPMの世界でも最近自動化されているものがたくさんあります。
多くの人が_apt-get_と_rpm -i_を使用してソフトウェアをインストールすることを比較しているため、DEBの方が良いと言えます。ただし、これはDEBファイル形式とは関係ありません。実際の比較は、dpkgとrpmとaptitude/_apt-*_とzypper/yumです。
ユーザーの観点からは、これらのツールに大きな違いはありません。 RPMおよびDEB形式はどちらも単なるアーカイブファイルであり、いくつかのメタデータが添付されています。どちらも同様に難解で、ハードコードされたインストールパス（うん！）があり、微妙な詳細のみが異なります。 _dpkg -i_と_rpm -i_はどちらも、コマンドラインで指定された場合を除いて、依存関係のインストール方法を理解する方法がありません。
これらのツールに加えて、_apt-..._またはzypper/yumの形式のリポジトリ管理があります。これらのツールは、リポジトリをダウンロードし、すべてのメタデータを追跡して、依存関係のダウンロードを自動化します。各単一パッケージの最終インストールは、低レベルツールに渡されます。
長い間、_apt-get_は膨大な量のメタデータを非常に高速に処理するのに優れていますが、yumは処理に時間がかかります。 RPMは、rpmfindなど、さまざまなディストリビューションで互換性のない10個以上のパッケージを見つけるサイトにも影響を受けていました。 Aptは、すべてのパッケージが同じソースからインストールされたため、DEBパッケージのこの問題を完全に隠しました。
私の意見では、zypperは実際にaptとのギャップを埋めており、最近RPMベースのディストリビューションを使用することを恥じる理由はありません。大きな互換性のあるパッケージインデックスに対して、手元のopenSUSEビルドサービスで使用するのは簡単ではありませんが、同じくらい良い方法です。
システム管理者の観点から見ると、主にパッケージ形式ではなくdpkg/rpmツールセットにいくつかの小さな違いがあることがわかりました。
dpkg-divertを使用すると、パッケージからのファイルを独自のファイルで置き換えることができます。/usrまたは/libでファイルを検索し、回答に/usr/localを使用しないプログラムがある場合、それは命の恩人になることができます。 アイデアは提案されましたが、私が知る限り、rpmでは採用されていません。最後にrpmベースのシステムを管理したとき（確かに数年前だったと思いますが、状況が改善した可能性があります）、rpmは常に変更された構成ファイルを上書きし、カスタマイズを
*.rpmsave（IIRC）に移動します。これにより、システムが少なくとも1回は起動できなくなりました。 Dpkgは、カスタマイズをデフォルトとして、何をすべきかを尋ねます。Rpmバイナリパッケージは、パッケージではなくファイルへの依存関係を宣言できるため、debパッケージよりも細かく制御できます。
RpmツールのバージョンN-1がインストールされているシステムにバージョンNのrpmパッケージをインストールすることはできません。これはdpkgにも当てはまるかもしれませんが、形式が頻繁に変更されることはありません。
Dpkgデータベースはテキストファイルで構成されています。 rpmデータベースはバイナリです。これにより、dpkgデータベースの調査と修復が容易になります。一方、何も問題がなければ、rpmの方がはるかに速くなる可能性があります（debをインストールするには、数千の小さなファイルを読み取る必要があります）。
Debパッケージは標準フォーマット（
ar、tar、gzip）を使用するため、debパッケージを簡単に検査し、ピンチ調整することができます。 Rpmパッケージはそれほど友好的ではありません。
RPM：
- 「標準化」（deb仕様がないことではない）
- 多くの異なるディストリビューションで使用されています（ただし、あるパッケージが別のパッケージで機能するとは限りません）。
- IIRCは、パッケージだけでなくファイルへの依存を許可します
DEB：
- 高まる人気
- 推奨事項と提案を許可します（おそらくより新しいRPMでも許可されます）
おそらく、より重要な質問は、パッケージ形式ではなく（両方が同等であるため）パッケージマネージャー（dpkg対yum対aptitudeなど）です。
いくつかの回答者が言ったように、特定のパッケージformatが明らかに優れていることはそれほど多くありません。技術的には、それらは多少比較可能です。私の観点から、多くの違い、そして人々がどちらか一方を他方よりも好む理由は、
- オリジナルのパッケージデザインの哲学と対象読者
- コミュニティーのサイズ、および拡張により、リポジトリーの品質と豊富さ
哲学：
Ubuntu/Debian/Mint/...の世界では、ユーザーは、インストールされたパッケージがインストールされると「動作する」ことを期待します。これは、インストール中に、パッケージが実際に正常に動作するために必要なすべてを処理することが期待されていることを意味します。
- 必須またはオプションのcronジョブの設定
- 代替/エイリアスの設定
- 起動/シャットダウンスクリプトの設定
- 意味のあるデフォルトのすべての必要な構成ファイルを含める
- ライブラリの古いバージョンを維持し、後方互換性のためにライブラリ（.so）に正しいバージョンのシンボリックリンクを追加
- 同じマシン上でのマルチアーチ（32および64ビット）バイナリのクリーンサポート。
Rpmの世界では-確かにこれは数年前の状況であり、それ以降は改善された可能性があります-実際にパッケージを実際に機能させるには、追加の手順（chkconfig、cronジョブを有効にするなど）を実行する必要があることがわかりました。これは、システム管理者やUnixに精通している人には問題ないかもしれませんが、初心者の経験を苦しめます。 RPMパッケージ形式自体がこれを防ぐのではなく、多くのパッケージが事実上「完全に完了」していないだけであることに注意してください。初心者の視点。
コミュニティのサイズ、参加、およびリポジトリの豊富さ：
Ubuntu/debian/mint/...コミュニティは大きいため、ソフトウェアのパッケージ化とテストに携わる人々が増えています。リポジトリの豊富さと品質は優れていると思いました。 Ubuntuでは、ソースをダウンロードしてビルドする必要があったとしても、めったにありません。私が自宅でRed HatからUbuntuに切り替えたとき、典型的なRHELリポジトリには〜3000個のパッケージがありましたが、同時に、すべてのCanonicalミラーから直接利用可能なubuntu + universe + multiverseには〜30,000個のパッケージ（およそ10倍）がありました。 RPM形式で探していたパッケージのほとんどは、単純な検索で簡単にアクセスできず、パッケージマネージャーでクリックできませんでした。代替リポジトリへの切り替え、rpmfindサービスのWebサイトの検索などが必要でした。これは、ほとんどの場合、問題を解決するのではなく、正しくアップグレードできる依存関係やアップグレードできない依存関係の制限に失敗して、インストールを壊しました。上記のShawn J. Goffが説明しているように、私は「依存関係の地獄」現象に遭遇しました。
対照的に、Ubuntu/Debianでは、ソースからビルドする必要はほとんどありません。また、次の理由により：
- Ubuntuの高速（6か月）リリースサイクル
- 完全に互換性のあるPPAがそのまま使用できる
- 単一のソースリポジトリ（すべてCanonicalがホスト）で、代替/補足リポジトリを検索する必要がない
- クリックから実行までのシームレスなユーザーエクスペリエンス
公式の（Canonical）開発者によってメンテナンスされていなかったとしても、気にかけていた古いバージョンのパッケージに妥協する必要はありませんでした。キーワードによる便利な検索を実行したり、必要なパッケージを見つけてインストールしたりするために、お気に入りの使いやすいGUIパッケージマネージャーを離れる必要はありませんでした。また、Ubuntuにdebian（非Canonical）パッケージを数回インストールしたところ、この互換性が公式に保証されていないにもかかわらず、それらは問題なく動作しました。
これは炎上戦争を開始することを意図したものではなく、両方の世界を数年間並行して使用した私の経験を共有していることに注意してください（仕事と家庭）。
バイアスはパッケージ形式からではなく、RedHatのリポジトリに存在していた不整合から来ていると思います。
RedHatがディストリビューションだった頃（RHEL、Fedora、Fedora Coreが登場する前）には、「RPM Hell」や「dependency Hell」に出くわすことがありました。これは、リポジトリが、相互に排他的な依存関係（通常は数層の深さ）を持つパッケージで終了するときに発生しました。または、2つの異なるパッケージに相互に排他的な依存関係が2つある場合にも発生します。これは、パッケージ形式ではなく、リポジトリの状態に関する問題でした。 「RPM Hell」は、問題に火傷したLinuxユーザーの一部の人々の間でRPMシステムに不満を残しました。
「哲学的」な違いもあり、Debianパッケージでは質問をして、これによってインストールプロセスをブロックできます。これの悪い面は、返信するまで一部のパッケージがアップグレードをブロックすることです。これの良い面は、哲学的な違いとして、Debianベースのシステムでは、パッケージがインストールされると、構成され（常に希望どおりとは限りません）、実行されます。/usr/share/doc/*からdefault/template設定ファイルを作成/コピーする必要があるRedhatベースのシステムにはありません。
RPMについて私が気に入っている点の1つは、（最近の？）差分RPMの追加です。これにより、更新が容易になり、必要な帯域幅が削減されます。
DEBは標準のarファイル（内部にはより標準的なアーカイブが含まれています）、RPMは「独自の」バイナリファイルです。個人的には前者の方が便利だと思います。
頭に浮かぶのは2つだけです。どちらも非常に似ています。どちらもパッケージングに優れたツールを備えています。私は他の人よりも多くのメリットがあるとは思いません。
Debianパッケージには インストールサイズ を含めることができますが、RPMに同等のフィールドがあるとは思いません。これは、パッケージに含まれているファイルに基づいて計算できますが、インストール前/後のスクリプトで実行できるアクションのため、信頼できません。
以下は、特定のパッケージ形式ごとに利用可能ないくつかの特定の機能を比較するためのかなり良いリファレンスです： http://debian-br.sourceforge.net/txt/alien.htm （ウェブによると）サーバー、そのドキュメントはかなり古いです：Last-Modified：Sun、15 Oct 2000したがって、これは最良のリファレンスではないかもしれません。）
OpenSUSEビルドサービス（OBS）とzypperは、パッケージャーとユーザーの観点から、debよりRPMを好む2つの理由です。 Zypperは長い道のりを歩んできました。 OBSは、debsを処理できますが、openSUSE、SLE、RHEL、centos、Fedora、mandrivaなどのさまざまなプラットフォーム用のrpmのパッケージングに関しては本当に素晴らしいです。
他のどの回答も、次の3つの基本の違いが実際にどのように影響するかについて触れていません。
debファイルは基本的に、2つの圧縮されたtarballを含むarアーカイブですdebパッケージとdpkgシステムは、メンテナースクリプトを個別のファイルとして保存しますdpkgおよびrpmは、アップグレード中に異なる順序でメンテナースクリプトを実行します。
これらの違いにより、はるかに簡単悪いパッケージによって引き起こされる問題を修正し、debベースのシステムでは、パッケージが私が必要とする方法で動作するようになりました。 rpmベースのシステム、両方システム管理者としてandパッケージャとして。
＃1のため、debファイルを変更する必要がある場合は、簡単に開いて、必要な変更を加えて再パッケージ化できますほとんどのシステムに存在する標準ツールを使用 =。
これには、依存関係、パッケージファイル、メンテナスクリプトの変更、追加、削除、パッケージのバージョンや名前の変更が含まれます。
＃2のため、パッケージによってインストールされた「削除」スクリプトに問題がある場合すでにインストールされています、簡単に修正できます任意のシステムに存在する標準ツールを使用）。
＃3のため、アップグレード中にdpkgがパッケージの新しいバージョンの「プレインストール」スクリプトを実行するため、パッケージの新しいバージョンをリリースするだけでこれらの修正の一部を実行できますbefore旧バージョンの「削除後」スクリプト。
これは、「回復可能性の原則」に違反するための表面積がdebパッケージで小さいことを意味します。以前のバージョンのパッケージでは、新しいバージョンでより多くのミスを回復できます。
また、パッケージの変更は非常に簡単なので、実際のパッケージ固有の操作や知識のオーバーヘッドはわずかです-debファイルを使用すると、より多くの人がアクセスでき、時間と労力がかかりません。
Debianパッケージの場合、ヘルパースクリプトの大規模なセット、一貫したポリシーマニュアル、およびほぼすべてを行う少なくとも1つの方法があります。依存関係は非常によく処理され、非常に細かく定義できます。パッケージの再構築は、debianパッケージを使用すると非常に簡単で、利用可能なツールによって十分にサポートされています。
Googleで検索
- rpm重複パッケージ
- dpkg重複パッケージ
戻ってくるページを読んでください。 dpkgではこのようなケースは発生しませんが、パッケージが重複しているめちゃくちゃなRPMデータベースが存在する可能性があることを非常に伝えています。