Answers:
软件包维护者的主要区别（我认为在Debian语言中将是“开发者”）是软件包元数据和随附脚本结合在一起的方式。
在RPM世界中，所有软件包（您维护的RPM）都位于~/rpmbuild。下面，有是SPEC你的规范，文件，目录SOURCES的源码包，目录RPMS和SRPMS目录把新创建RPM和的SRPM成，和其他一些东西，现在是不相关的。
与如何创建RPM有关的一切都在spec文件中：将应用哪些补丁，可能的前脚本和后脚本，元数据，变更日志等等。所有源tarball和所有软件包的所有补丁都在SOURCES中。
现在，个人而言，我喜欢所有内容都进入规范文件，而且规范文件是与源tarball分开的实体这一事实，但是我对在SOURCES中拥有所有源并不十分热衷。恕我直言，来源很快就会变得混乱不堪，您往往会忘记其中的内容。但是，意见不同。
对于RPM，重要的是使用与上游项目发布的tarball 完全相同的 tarball，直到时间戳记为止。通常，此规则没有例外。Debian软件包也需要与上游相同的tarball，尽管Debian策略要求将一些tarball重新打包（谢谢，Umang）。
Debian软件包采用了不同的方法。（在这里避免出现任何错误：我对Deb的经验远不如对RPM的经验。）Debian软件包的开发文件包含在每个软件包的目录中。
我（想）喜欢这种方法的事实是，所有内容都包含在一个目录中。
在Debian的世界中，在尚未（还）上游的软件包中携带补丁程序已被接受。在RPM世界中（至少在Red Hat衍生产品中），这是不受欢迎的。请参阅“ FedoraProject：与上游项目保持联系”。
而且，Debian有大量的脚本，能够自动执行创建软件包的很大一部分。例如，创建一个由setuptooled处理的Python程序的简单包，就像创建几个元数据文件并运行一样简单debuild。也就是说，RPM格式的此类软件包的规范文件非常短，在RPM领域中，如今也有很多自动化的东西。
.diff.gz或.debian.tar.gz文件中，尽管debian提取源软件包时该目录位于源树中。顺便说一句：当策略不需要重新打包时，压缩包的MD5必须与上游压缩包的MD5相匹配。另外，为澄清起见，我作为上游源维护者的补丁存储在debian目录（源格式3.0）和.diff.gz（格式1.0）中。
很多人将安装软件与apt-get进行比较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）。这使我的系统至少无法启动一次。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不再能够打开新软件包。
千次曝光收益：
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服务网站等。在大多数情况下，这并不是解决问题，由于无法限制可以正确升级或不能正确升级的依赖项而中断了我的安装。正如Shawn J. Goff所描述的，我遇到了“依赖地狱”现象。
相反，在Ubuntu / Debian中，我发现几乎不需要从源代码进行构建。也因为：
即使我不是由官方（规范）开发人员维护的软件包，我也不必在我关心的旧版本上妥协。我从不需要离开我最喜欢的友好GUI软件包管理器来通过关键字执行便捷的搜索，以查找并安装我想要的任何软件包。另外，有几次我在Ubuntu上安装了debian（非Canonical）软件包，尽管不能正式保证这种兼容性，但它们工作得很好。
请注意，这并不是要引发一场火焰大战，它只是分享我在两个环境中并行使用几年（工作与家庭）的经验。
还有一个“哲学上的”区别，在Debian软件包中，您可以提出问题，从而阻碍了安装过程。不利的一面是，某些软件包将阻止您的升级，直到您回复为止。从哲学上来说，这样做的好处是，在基于Debian的系统上，安装了软件包后，就可以对其进行配置（不一定总是按您的意愿）并运行它。不是在需要从/ usr / share / doc / *创建/复制默认/模板配置文件的基于Redhat的系统上。
我喜欢RPM的一件事是（最近？）增加了增量RPM。这样可以更轻松地更新，减少所需的带宽。
DEB是标准的ar文件（内部带有更多标准档案），RPM是“专有”二进制文件。我个人认为前者更方便。
我能想到的只有两件事。两者非常可比。两者都有出色的包装工具。我认为，一个优点没有另一个优点，反之亦然。
rpm2cpio.sh脚本。
从打包程序和用户的角度来看，openSUSE Build Service（OBS）和zypper是我更喜欢RPM而不是deb的两个原因。Zypper已经走了很长一段路，而且还挺快的。OBS虽然可以处理deb，但是在打包各种平台（例如openSUSE，SLE，RHEL，centos，fedora，mandriva等）的rpm时，它确实很棒。
对于Debian软件包，有大量的帮助程序脚本，一致的策略手册以及至少一种完成几乎所有事情的方式。依赖关系处理得很好，并且可以以非常好的粒度进行定义。使用debian软件包可以很容易地重建软件包，并得到可用工具的良好支持。
其他答案都没有涉及以下三个基本差异如何产生实际后果：
deb文件基本上只是ar包含两个压缩tarball的档案deb软件包和dpkg系统将您的维护者脚本存储为单独的文件dpkg并rpm在升级过程中以其他顺序运行维护者脚本。总之，这些差异使人们更容易为我解决不好造成的封装问题，并提出包的行为，我需要他们的样子，就deb不是基于系统rpm的系统上，两者作为一个系统管理员，并作为一个打包。
由于＃1，如果我需要更改deb文件，则可以使用大多数系统上存在的标准工具轻松地将其弹出，进行所需的任何更改，然后重新打包。
这包括更改/添加/删除任何依赖性，任何软件包文件或任何维护者脚本，或更改软件包版本或名称。
由于＃2，如果已经安装的软件包所安装的“删除”脚本中存在问题，我可以使用任何系统上存在的标准工具来对其进行简单修复。
由于＃3，我可以仅通过发布软件包的新版本来进行某些修复，因为在升级过程中，dpkg将在软件包的“后删除”脚本之前运行软件包新版本的“预安装”脚本。旧版本。
这意味着在deb包装中违反“可回收性原则”的表面积较小：在新版本中可以恢复较早版本的包装中的更多错误。
而且，由于修改软件包非常容易-特定于软件包的实际摆弄和知识开销很小-它可供更多的人访问，并且使用deb文件花费的时间和精力更少。
debian目录存在于上游源提取到的目录中，并且Debian确实非常重视原始上游源tarball的概念。生成源软件包时，将有三个文件（对于本机软件包为两个），这些文件一起称为源软件包：上游tarball（最好是原始的，Debian策略要求重新打包某些项目），debian目录的tarball用于新的3.0格式（旧的1.0格式的差异）和.dsc。