deb 與 rpm 的優缺點是什麼？
無論出於何種原因，我一直使用基於 RPM 的發行版（Fedora、Centos 和目前的 openSUSE）。我經常聽到它說 deb 比 rpm 好，但是當被問及為什麼時，始終無法得到一個連貫的答案（通常會得到一些狂熱的咆哮和大量的唾沫）。
我知道可能有一些歷史原因，但是對於使用兩種不同包裝方法的現代發行版，任何人都可以給出一個與另一個的技術（或其他）優點嗎？
包維護者（我認為這將是 Debian 術語中的“開發者”）的主要區別在於包元數據和隨附腳本的組合方式。
在 RPM 世界中，您的所有軟體包（您維護的 RPM）都位於類似
~/rpmbuild. 下面是SPEC您的規範文件的SOURCES目錄、源 tarballRPMS的SRPMS目錄、新創建的 RPM 和 SRPM 的目錄，以及其他一些現在不相關的東西。與如何創建 RPM 有關的所有內容都在規範文件中：將應用哪些更新檔、可能的前後腳本、元數據、變更日誌等等。**所有原始碼壓縮包和所有包的所有更新檔都在 SOURCES 中。
現在，就個人而言，我喜歡一切都進入規範文件的事實，並且規範文件是與源 tarball 分開的實體，但我並不太熱衷於在 SOURCES 中擁有所有源。恕我直言，SOURCES 很快就會變得混亂，你往往會忘記那裡有什麼。然而，意見不一。
對於 RPM，重要的是使用與上游項目發布的*完全相同的tarball，直到時間戳。*一般來說，這條規則沒有例外。Debian 軟體包也需要與上游相同的 tarball，儘管 Debian 政策要求重新打包一些 tarball（感謝 Umang）。
Debian 軟體包採用不同的方法。（請原諒這裡的任何錯誤：我對 deb 的經驗比對 RPM 的經驗要少得多。）Debian 軟體包的開發文件包含在每個軟體包的一個目錄中。
我（認為）喜歡這種方法的原因是所有內容都包含在一個目錄中。
在 Debian 世界中，在包中攜帶尚未（還）上游的更新檔更容易被接受。在 RPM 世界（至少在 Red Hat 衍生產品中），這是不受歡迎的。請參閱“FedoraProject：與上游項目保持密切聯繫”。
此外，Debian 有大量的腳本可以自動創建一個包的很大一部分。例如，創建一個 setuptool 的 Python 程序的簡單包，就像創建幾個元數據文件並執行
debuild. 也就是說，這種 RPM 格式的包的規範文件會很短，而且在 RPM 世界中，如今也有很多東西是自動化的。
很多人將安裝軟體與
apt-getto進行比較rpm -i，因此說 DEB 更好。然而，這與 DEB 文件格式無關。真正的比較是dpkgvsrpm和aptitude/apt-*vszypper/yum。從使用者的角度來看，這些工具沒有太大區別。RPM 和 DEB 格式都只是存檔文件，附加了一些元數據。它們都同樣神秘，具有硬編碼的安裝路徑（糟糕！），並且僅在細微的細節上有所不同。兩者
dpkg -i都rpm -i無法弄清楚如何安裝依賴項，除非它們恰好在命令行上指定。在這些工具之上，還有以 / 形式存在的儲存
apt-...庫管理zypper。yum這些工具下載儲存庫、跟踪所有元數據並自動下載依賴項。每個單獨包的最終安裝都交給低級工具。長期以來，
apt-get在處理大量元數據方面一直表現出色，但需要很長時間yum才能完成。RPM 還受到 rpmfind 之類的站點的影響，您會在其中找到 10 多個針對不同發行版的不兼容軟體包。Apt完全隱藏了 DEB 包的這個問題，因為所有包都是從同一個源安裝的。在我看來，
zypper它確實縮小了差距，apt而且現在沒有理由為使用基於 RPM 的發行版感到羞恥。與手頭的 openSUSE 建構服務一起使用它同樣好，甚至更容易，以獲得巨大的兼容包索引。