回答:
パッケージメンテナー（Debianの用語では「開発者」になると思います）の主な違いは、パッケージのメタデータとそれに付随するスクリプトが一緒になる方法です。
RPMの世界では、すべてのパッケージ（管理するRPM）はのような場所にあります~/rpmbuild。下に、そこにあるSPEC、あなたのスペック・ファイル、ディレクトリSOURCESソースのtarballのディレクトリ、RPMSおよびSRPMSディレクトリに新しく作成されたRPMとSRPMSを入れて、そして今では関係ありませんいくつかの他のもの。
RPMの作成方法に関係するものはすべて specファイルにあります。適用されるパッチ、適用可能なプリスクリプトとポストスクリプト、メタデータ、変更ログ、すべて。すべてのソースtarballとすべてのパッケージのすべてのパッチはSOURCESにあります。
今、個人的には、すべてが仕様ファイルに組み込まれ、仕様ファイルがソースtarballとは別のエンティティであるという事実が好きですが、すべてのソースをSOURCESに入れることにあまり熱心ではありません。私見、ソースは非常に迅速に乱雑になり、そこにあるもののトラックを失う傾向があります。ただし、意見は異なります。
RPMでは、アップストリームプロジェクトがリリースするものとまったく同じtarballをタイムスタンプまで使用することが重要です。一般に、この規則に例外はありません。Debianパッケージもアップストリームと同じtarballを必要としますが、Debianポリシーでは一部のtarballを再パッケージする必要があります（ありがとう、Umang）。
Debianパッケージは異なるアプローチを取ります。（ここで誤りを許してください：RPMを使っているよりもdebの経験がはるかに少ないです。）Debianパッケージの開発ファイルはパッケージごとのディレクトリに含まれています。
このアプローチについて私が（考えている）ことは、すべてが単一のディレクトリに含まれているという事実です。
Debianの世界では、（まだ）アップストリームではないパッケージでパッチを運ぶことはもう少し受け入れられています。RPMの世界（少なくともRed Hatの派生製品）では、これは嫌われています。「FedoraProject：アップストリームプロジェクトの近くに滞在する」を参照してください。
また、Debianには、パッケージ作成の大部分を自動化できる膨大な量のスクリプトがあります。たとえば、setuptool'ed Pythonプログラムの-simple-パッケージの作成は、いくつかのメタデータファイルを作成してを実行するのと同じくらい簡単debuildです。そうは言っても、RPM形式のこのようなパッケージの仕様ファイルはかなり短く、RPMの世界でも、最近自動化されたものがたくさんあります。
.diff.gzまたは.debian.tar.gzファイルに残りますdebian。ところで：ポリシーが再パッケージ化を必要としない場合、tarballのMD5は上流のtarballのMD5と一致する必要があります。また、明確にするために、アップストリームソースのメンテナーになったパッチは、debianディレクトリ（ソースフォーマット3.0）と.diff.gz（フォーマット1.0）に保存されています。
多くの人がソフトウェアのインストールとapt-gettoを比較しrpm -i、したがってDEBの方が良いと言います。ただし、これはDEBファイル形式とは関係ありません。実際の比較はdpkgvs rpmとaptitude/ apt-*vs 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パッケージよりも細かく制御できます。
バージョンN-1のrpmツールを使用してシステムにバージョンN rpmパッケージをインストールすることはできません。これはdpkgにも当てはまるかもしれませんが、フォーマットがそれほど頻繁に変わらないことを除きます。
dpkgデータベースはテキストファイルで構成されています。rpmデータベースはバイナリです。これにより、dpkgデータベースの調査と修復が簡単になります。一方、何も問題がなければ、rpmははるかに高速になります（debをインストールするには、数千の小さなファイルを読み込む必要があります）。
debパッケージは、標準形式を使用しています（ar、tar、gzip）ので、簡単）のdebパッケージを検査し、ピンチ微調整ですることができます。Rpmパッケージは、それほどフレンドリーではありません。
*.rpmnew少なくともopenSUSEで、変更したファイルを上書きする代わりに新しい設定ファイルを保存しているように見えます。
rpm2cpio.sh、それらの傾向がある人のためにあります。
deb私が覚えている形式の唯一の重大な変更はにdata.tar.gzなったときdata.tar.xzで、その時点で古いdpkgパッケージは新しいパッケージを開けなくなりました。
RPM：
DEB：
おそらく、より重要な質問は、パッケージ形式（両方が同等であるため）ではなく、パッケージマネージャー（dpkg対yum対aptitudeなど）です。
いくつかのレスポンダーが言ったように、特定のパッケージ形式が明らかに優れているということではありません。技術的には、それらはほぼ同等です。私の観点から見ると、多くの違いと、なぜ人々が他のどちらよりも好むのかは、次のことに関係しています。
哲学：
Ubuntu / Debian / Mint / ...の世界では、ユーザーはインストールされたパッケージがインストールされると「正常に動作する」ことを期待しています。これは、インストール中に、パッケージが実際に適切に実行するために必要なすべてを処理することが期待されることを意味します。
rpmの世界では-確かにこれは数年前の状況であり、それ以降は改善されている可能性があります-実際にパッケージを実際に動作させるには、追加の手順（chkconfig、cronジョブの有効化など）を実行する必要があります。これは、システム管理者やUnixに精通している人にとっては問題ないかもしれませんが、初心者の経験を苦しめます。RPMパッケージのフォーマット自体がこれを防ぐのではなく、多くのパッケージが初心者の観点からは「完全に行われていない」という事実にすぎないことに注意してください。
リポジトリーのコミュニティーのサイズ、参加、および豊富さ：
ubuntu / debian / mint / ...コミュニティの規模が大きいため、ソフトウェアのパッケージ化とテストに携わる人が増えています。リポジトリの豊富さと品質が優れていることがわかりました。ubuntuでは、ソースをダウンロードしてビルドする必要はほとんどありません。自宅でRed HatからUbuntuに切り替えたとき、典型的なRHELリポジトリには〜3000個のパッケージが含まれていましたが、同時に、Canonicalミラーから直接利用可能なubuntu + universe + multiverseには〜30,000個のパッケージ（約10倍）がありました。RPM形式で探していたパッケージのほとんどは、単純な検索とパッケージマネージャーのクリックでは簡単にアクセスできませんでした。代替リポジトリへの切り替え、rpmfindサービスWebサイトの検索などが必要でした。ほとんどの場合、これは問題を解決するのではなく、依存関係を正しくアップグレードできるかできないかを制限しなかったため、インストールが中断されました。上記のショーンJ.ゴフが説明したように、「依存性地獄」現象にぶつかりました。
対照的に、Ubuntu / Debianでは、ソースからビルドする必要はほとんどありません。また、次の理由によります。
公式（正規）開発者によって保守されていない場合でも、気にするパッケージの古いバージョンで妥協する必要はありませんでした。キーワードで便利な検索を行い、必要なパッケージを見つけてインストールするために、お気に入りの使いやすいGUIパッケージマネージャーを離れる必要はありませんでした。また、debian（non Canonical）パッケージをUbuntuに数回インストールしたところ、この互換性が公式に保証されていないにもかかわらず、問題なく機能しました。
これは炎の戦争を開始することを意図していないことに注意してください、それはちょうど両方の世界を数年間並行して使用した私の経験を共有しているだけです（仕事対自宅）。
バイアスは、パッケージ形式ではなく、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つだけです。どちらも非常に類似しています。どちらもパッケージングに優れたツールを備えています。私は、一方が他方に対してそれほど多くのメリットがあるとは思わない。
rpm2cpio.shスクリプトを見つけることができます。
openSUSE Build Service（OBS）とzypperは、パッケージャーとユーザーの観点からdebよりRPMを好むいくつかの理由です。Zypperは長い道のりを歩んできました。OBSはdebsを処理できますが、openSUSE、SLE、RHEL、centos、fedora、mandrivaなどのさまざまなプラットフォーム用のrpmのパッケージングに関しては本当に素晴らしいです。
Debianパッケージにはインストール済みのサイズを含めることができますが、RPMに同等のフィールドがあるとは思いません。パッケージに含まれるファイルに基づいて計算できますが、インストール前後のスクリプトで実行できるアクションのために依存することもできません。
特定のパッケージ形式ごとに利用できる特定の機能を比較するための参考資料を次に示します。http：//debian-br.sourceforge.net/txt/alien.htm（Webサーバーによると、その文書はかなり古い：最終変更日：2000年10月15日（日）
Debianパッケージには、多数のヘルパースクリプト、一貫性のあるポリシーマニュアル、およびほぼすべてを行うための少なくとも1つの方法があります。依存関係は非常によく処理され、非常に細かい粒度で定義できます。パッケージの再構築は、debianパッケージで非常に簡単であり、利用可能なツールで十分にサポートされています。
他の答えはどれも、次の3つの基本的な違いが実際にどのような結果をもたらすかについて触れていません。
debファイルは基本的にar2つの圧縮されたtarballを含む単なるアーカイブですdebパッケージとdpkgシステムは、メンテナースクリプトを個別のファイルとして保存しますdpkgそしてrpm、アップグレード中に異なるために、メンテナスクリプトを実行します。一緒に、これらの違いは、それが作った方がはるかに簡単に私が悪いのパッケージによって引き起こされる問題を修正して、そしてパッケージが上、私はそれらを必要とするように動作させるためにのためdebによりベースのシステムrpm、ベースのシステムの両方のシステム管理者としておよびパッケージャとして。
＃1により、debファイルを変更する必要がある場合、ほとんどのシステムに存在する標準ツールを使用して、ファイルを簡単にポップし、必要な変更を加え、再パッケージ化できます。
これには、依存関係、パッケージファイル、メンテナースクリプトの変更、追加、削除、またはパッケージのバージョンや名前の変更が含まれます。
＃2のため、既にインストールされているパッケージによってインストールされた「remove」スクリプトに問題がある場合、任意のシステムに存在する標準ツールを使用して、それを簡単に修正できます。
＃3のため、パッケージの新しいバージョンをリリースするだけでこれらの修正の一部をdpkg実行できます。アップグレード中に、パッケージの新しいバージョンの「プレインストール」スクリプトを実行してから、古いバージョン。
これは、「回復可能性の原則」に違反する表面積がdebパッケージ内で小さくなることを意味します。パッケージの以前のバージョンでのより多くの間違いは、新しいバージョンで回復できます。
また、パッケージの変更は非常に簡単です（実際のパッケージ固有の操作と知識のオーバーヘッドは小さいため）。多くの人がアクセスでき、debファイルを使用することで時間と労力を削減できます。
debianに、ディレクトリはアップストリームソースが抽出されたディレクトリに存在し、Debianは原始的なアップストリームソースtarballの概念を非常に重視しています。ソースパッケージがビルドされると、ソースパッケージと呼ばれる3つのファイル（ネイティブパッケージ用に2つ）があります。新しい3.0形式（古い1.0形式の差分）と.dsc。