何らかの理由で、私は常にRPMベースのディストリビューション（Fedora、Centos、および現在openSUSE）を使用してきました。私はしばしば人々がdebがrpmより優れていると言うのを聞いています。しかし、理由を尋ねたとき、決して一貫した答えを得ることはできません（通常、情熱的な好言状と多くの唾液を吐きます）。
いくつかの歴史的な理由があるかもしれないことを知っていますが、2つの異なるパッケージング方法を使用する現代のディストリビューションの場合、どちらか一方と他のものの技術的（または他の）利点を伝えることができる人はいますか？
答え1
多くの人は、ソフトウェアのインストールをDEBとapt-get比較して、rpm -iDEBが良いと言います。しかし、これはDEBファイル形式とは何の関係もありません。実際の比較はdpkgvsrpmとaptitude/ apt-*vs zypper/ですyum。
ユーザーの観点から見ると、これらのツール間に大きな違いはありません。 RPMとDEBの両方の形式は、いくつかのメタデータが添付されたアーカイブファイルです。どちらも同じように曖昧で、インストールパスがハードコードされている（うん！）、マイナーな詳細だけが異なります。dpkg -iどちらもrpm -iコマンドラインで指定されていない限り、依存関係をインストールする方法はわかりません。
apt-...これらのツールに加えてzypper。yumこれらのツールはリポジトリをダウンロードし、すべてのメタデータを追跡し、自動的に依存関係をダウンロードします。各個別パッケージの最終インストールは、下位レベルのツールに委ねられます。
これは、完了するのに長い時間がかかる大量apt-getのメタデータを迅速に処理するのに長い間優れていました。yumRPMはrpmfindなどのサイトの影響を受けます。このサイトでは、10を超えるディストリビューションに互換性のないパッケージを見つけることができます。AptDEBパッケージのこの問題は、すべてのパッケージが同じソースからインストールされるため、完全に隠されています。
私の考えでは、これがzypper実際にギャップを減らし、aptRPMベースのディストリビューションを使用するのを恥じる理由はありません。 OpenSUSEビルドサービスを使用して互換性のあるパッケージの巨大なインデックスを取得するのも簡単ではありませんが、それは良いことです。
答え2
パッケージマネージャ（Debianの用語では「開発者」だと思います）の主な違いは、パッケージメタデータとそれに付随するスクリプトが一緒に提供される方法です。
RPM 世界ですべてのパッケージ（維持管理するRPM）は~/rpmbuild。今関係のないコンテンツです。SPECSOURCESRPMSSRPMS
すべてRPMの生成方法に関する内容は仕様ファイルにあります。適用するパッチ、可能な辞書およびポストスクリプト、メタデータ、変更ログなどがあります。すべてのソースタールボールとすべてのパッチすべてのパッケージソースから。
今個人的に私はすべてが仕様ファイルに入り、仕様ファイルがソースターボールとは別のエンティティであるという事実が好きですが、みんなソース内のソース。 IMHO、ソースはすぐに混乱する可能性があり、その内容を忘れる傾向があります。しかし、意見は異なります。
RPMの場合精密アップストリームプロジェクトでリリースされた圧縮パッケージと同じで、タイムスタンプまで同じです。通常、この規則には例外はありません。 Debianパッケージにはアップストリームと同じタールボールが必要ですが、Debianポリシーでは一部のタールボールを再パッケージする必要があります（ありがとう、Umang）。
Debian パッケージは異なるアプローチをとります。 （ここにエラーがある場合は申し訳ありませんが、私はRPMよりもdebの経験がはるかに少ないです。）Debianパッケージの開発ファイルはパッケージごとのディレクトリに含まれています。
私がこのアプローチが好きなのは、すべてが1つのディレクトリに含まれているからです。
Debian の世界では、（まだ）上流ではなくパッケージにパッチを含めることができます。 RPMの世界では（少なくともRed Hat派生製品の中で）、これは人気がありません。バラより「Fedoraプロジェクト：アップストリームプロジェクトとの緊密な接続を維持する」。
さらに、Debian にはパッケージ作成タスクの大部分を自動化するスクリプトがたくさんあります。たとえば、setuptoolで処理されるPythonプログラムの単純なパッケージを作成すると、いくつかのメタデータファイルが作成されますdebuild。今、多くのものが自動化されています。
答え3
システム管理者の観点から、主にパッケージ形式ではなく、dpkg / rpmツールセットにいくつかの微妙な違いがありました。
dpkg-divertパッケージ内のファイルを独自のファイルに置き換えることができます。回答を見つけたり、ファイルを探すことなく/usrファイルを探すプログラムがある場合は、命の恩人になることができます。/lib/usr/localこのアイデアは提案されていますが、私が知っている限り、rpm単位で採用されていません。私が最後にrpmベースのシステムを管理したとき（もちろん数年前ですが、状況は改善された可能性があります）、rpmは常に変更された設定ファイルを上書きし、私のカスタマイズを
*.rpmsaveIIRCに移動しました。これにより、システムが複数回起動できなくなりました。 Dpkgは私に何をすべきか尋ね、私のカスタム設定をデフォルトにしています。RPMバイナリパッケージは、パッケージではなくファイルへの依存関係を宣言することができるため、debパッケージよりも強力な制御が可能です。
バージョンN-1 rpmツールを搭載したシステムには、バージョンN rpmパッケージをインストールできません。フォーマットが頻繁に変更されないことを除いて、dpkgでも機能できます。
dpkg データベースはテキストファイルで構成されます。 rpm データベースはバイナリです。これにより、dpkgデータベースを簡単に調査して回復できます。一方、問題がなければ、rpmははるかに高速です（debをインストールするには数千の小さなファイルを読む必要があります）。
debパッケージは標準形式（
ar、、、tar）gzipを使用しているため、debパッケージを簡単に確認し、必要に応じて調整できます。 RPMパッケージはあまり馴染みがありません。
答え4
複数の回答者が言ったように、パッケージと言うよりも滞在明らかに優れています。技術的にはやや似ているかもしれません。私の観点から見ると、多くの違いと人々が異なることを好む理由は、次の要因に関連しています。
- オリジナルの包装デザインコンセプトとターゲット顧客
- コミュニティ規模、リポジトリの品質と豊かさ
哲学：
Ubuntu/Debian/Mint/... 世界では、ユーザーはインストールされたパッケージがインストールされたら「正しく動作する」ことを期待しています。これは、インストール中にパッケージに次のものが含まれますが、これらに限定されず、実際に正しく実行されるために必要なすべてを処理する必要があることを意味します。
- 必須またはオプションのクローン操作の設定
- 代替/エイリアス設定
- スタート/終了スクリプトの設定
- 意味のあるデフォルト値とともに、必要なすべての構成ファイルが含まれています。
- 以前のバージョンのライブラリを維持し、古いバージョンとの互換性を確保するために、正しいバージョンのシンボリックリンクをライブラリ（.so）に追加してください。
- 同じシステムでマルチアーキテクチャ（32ビットおよび64ビット）バイナリなどを完全にサポートします。
rpmの世界では - 確かにこれは数年前のものであり、それ以来わずかに改善されている可能性があります。 - パッケージが実際に機能するようにするには、追加の手順（chkconfig、cronジョブを有効にするなど）を実行する必要があることがわかりました。これはシステム管理者やUnixを知っている人にとっては大丈夫かもしれませんが、初心者にとっては難しいかもしれません。この問題が発生するのを防ぐことは、RPMパッケージ形式自体ではなく、多くのパッケージが実際にこれらの現象を防止しないことに注意してください。「完全に完了しました」初心者の観点から。
コミュニティ規模、参加、リポジトリの豊富さ:
ubuntu/debian/mint/... コミュニティの規模が大きいため、ソフトウェアのパッケージングやテストに参加する人が多いです。私は店の豊かさと品質が優れていることがわかりました。 Ubuntuでは、ソースコードをダウンロードしてビルドする必要はほとんどありません。自宅でRed HatからUbuntuに切り替えたとき、通常のRHELリポジトリには約3000個のパッケージがあり、同時にCanonicミラーで直接使用できるubuntu+universe+multiverseには約30,000個のパッケージがありました（約10回）。 ）。私が探しているRPM形式のパッケージのほとんどは、パッケージマネージャで簡単な検索とクリックで簡単にアクセスできません。代替リポジトリに切り替えて、rpmfindサービスのWebサイトを検索する必要があります。ほとんどの場合、問題は解決されませんが、正しくアップグレードできない、またはアップグレードできない依存関係を制限できず、インストールが中断されます。 Shawn J. Goffの回答に記載されているように、「依存性地獄」現象が発生しました。
対照的に、Ubuntu / Debianではソースからビルドする必要がほとんどないことがわかりました。また、次の理由から：
- Ubuntuクイック（6ヶ月）リリースサイクル
- 存在感完全に互換性すぐに利用可能なPPA
- 単一ソースリポジトリ（すべてCanonicでホストされている）代替/補完リポジトリを検索する必要はありません。
- クリックから実行までのシームレスなユーザー体験
私は、私が興味を持っていた以前のバージョンのパッケージを公式（正規）の開発者が維持しなくても妥協する必要はありませんでした。私が好きなパッケージを見つけてインストールするためにキーワードで便利な検索を実行するために、私のお気に入りのおなじみのGUIパッケージマネージャを残す必要はありません。また、UbuntuにDebian（非標準）パッケージを数回インストールしましたが、この互換性は正式に保証されていませんが、うまく機能します。
これは激しい戦争を始めようとする意図ではなく、長年にわたって2つの世界（職場と家庭）を行き来し、経験した内容を共有することです。