rpm 不是开放标准

为什么 rpm 不是开放标准

rpm 的问题在于没有规范。rpm 接受的是有效的软件包，rpm 对其的处理是软件包的正确解释。随着软件包管理器的更改，这会随着时间而演变。

没有 spec 文件和宏文件语法的规范

spec 文件语法没有文档记录。虽然存在针对特定用例的指南，但完整的语法规范并不存在。spec 文件语法与嵌入式 shell 脚本的语法之间存在复杂的交互。这些交互以及各种宏构造的扩展程度因 rpm 版本而异。类似的变体是宏文件，它们定义了可以在 spec 文件中使用的宏。相比之下，许多其他打包格式使用明确定义的语法 - dpkg 使用 makefile 作为构建配方，并且 makefile 语法和语义都经过详细定义。

没有软件包元数据的规范

软件包元数据，尤其是软件包依赖项没有文档记录。存在针对特定用例的指南，但不同依赖项的确切含义未定义。这意味着 rpm 或求解器对您的软件包的处理方式只能通过试验这些工具的不同版本来确定，并且不同版本之间的依赖项处理差异确实存在。相比之下，Debian 具有打包策略手册，该手册详细描述了可以出现在 dpkg 软件包中的每个字段及其含义。

缺乏开放打包标准的后果

如果没有标准，您必须接受有效的软件包以及您的软件包的处理方式可以在任何时候未经通知而更改。这并非一个理论问题 - rpm 中的破坏性更改确实发生过。

另一个问题是，对于任何给定的行为，不清楚它是 rpm 和求解器功能还是错误。这反过来意味着在软件包管理器中实施任何更改都很困难，并且找到新的开发人员来从事这项工作几乎是不可能的。

最后，任何打包工作以及任何具有超出打包指南中描述的常见用例的打包需求的项目的包装工作都需要由已经稀缺的 rpm 和求解器开发人员进行门控，以确定可行性和正确性。这反过来会给开发人员带来过载，并导致分发创新受到抑制。

概述

关于 RPM 无法正确解析依赖项的一些旧刻板印象是针对 rpm 及其使用它的发行版（包括 openSUSE）的批评的基础。这些人责怪软件包格式或 rpm 程序，而实际上，问题在于围绕核心开发的工具。

一个常见的错误是将 rpm 与 apt-get 进行比较，而比较应该与 dpkg 进行。

几年前，rpm depsolvers（从技术上讲，它们被称为 depsolvers）承认不如 Debian 中著名的 apt 强大。对打包交互不太了解的人们做出了 .debs 优于 RPM 的推论。事实上，apt 被移植到处理 rpm 软件包中，作为现有 rpm 工具的权宜之计。

如今，rpm 依赖项解析问题已经解决。由 SUSE 大部分开发的 zypper 以及由 RedHat/Fedora 大部分开发的 yum 都是成熟且可靠的 depsolvers。

RPM vs DEB (格式)

RPM 是 LSB 标准。DEB 不是。
RPM 支持 xz 压缩。deb 也支持 xz 压缩，并且 dpkg-buildpackage 默认使用它。
实际上，Debian 及其衍生项目仍然几乎完全使用 .gz，尽管 deb 格式据称支持 gzip、bzip2、xz 和 LZMA (WP)。这导致软件包更大，安装和在线更新速度更慢。
- Fedora 使用 xz，openSUSE 使用旧的 LZMA
RPM 由内部元数据加上包含文件的单个 cpio 归档文件组成。DEB 使用 Unix ar(1) 归档文件，其中包含两个 tarball。

构建软件包

RPM specfile 使用以不明确方式混淆的 shell - 没有 spec 文件语法规范。但是，DEB 使用 Makefile-Shell 语法，该语法经过精确记录。
要创建一个 RPM 软件包，非 tarball 文件的最小数量是一个——该.spec文件本身。该文件包含以不明确格式的许多资源，这些资源相互依赖，因此无法单独提取和检查。DEB 软件包通常有 5 到 7 个（control, watch, rules等），这些软件包经过精确定义。
RPM 多年来使用标准（“quilt 类型”）补丁。DEB 从 2014 年起主要使用 quilt。
DEB 不允许在软件包名称和版本中使用“_” （导致奇怪的重命名狂欢，例如 pam_mount -> libpam-mount）
软依赖项，如“推荐”和“建议”，在 RPM 和 DEB 中都是可能的。
capabilities（provides）在 RPM 和 DEB 中都是可能的，但对于 RPM，它们仅在某些依赖项中有效。
RPM（使用 rpm ≥ 4.10，用于 openSUSE 12.3/Fedora 18 及更高版本）现在支持版本，如“1.0~beta2”（这在低于 1.0 排序）。这意味着在使用官方 rpm 二进制文件构建时，不再需要像“0.99_1.0.beta2”这样的黑客行为。
RPM 和 DEB 都有在整个事务结束时运行的软件包脚本，但对于 RPM，它们仅在安装时运行，而不是卸载时运行。

rpm vs dpkg (工具)

http://jengelh.medozas.de/linux/adm_pack.php — 请填写任何缺失的部分
RPM 作为一体化工具来执行软件包查询；在 Debian 方面，有 dpkg 和 dpkg-query。
RPM 允许安装同一软件包的多个版本（相同名称）。
RPM 和 DEB 允许安装同一软件包的多个架构（相同名称和版本）。但是，在实践中，rpm -U 很少这样做，因为它会导致“意外”结果（显然，它会升级，而升级意味着删除所有先前版本）。自从添加多架构支持以来，dpkg 可以优雅地处理此问题。
RPM 具有各种级别的差异化技术：patch.rpm 和 delta.rpm。DEB 世界似乎没有使用此类技术。
不需要额外的“purge”步骤（`apt-get purge`）在 RPM 中，因为 rpm 不跟踪 dpkg 刷除的状态。
dpkg 跟踪软件包安装/删除期间的脚本执行状态，以便可以恢复中断的事务。不幸的是，此状态与原始软件包元数据混合在一个巨大的文本文件中，该文件解析速度慢，不可靠，并且在损坏时无法恢复，因为它包含已运送在软件包中的数据。

Zypper vs APT

libzypp 具有 satsolver。apt 只有启发式搜索器。
zypper 具有供应商锁定。（不再允许来自第三方存储库的更新中的“软件包接管”。）
可以将文件指定为“zypper install”的参数。
命令行 apt 软件包搜索使用 apt-cache 有点笨拙 - 它返回的结果根本不包含搜索字符串（可能是因为它搜索更长的软件包描述）。在大多数情况下，人们希望将其通过管道传递给 grep 以产生 `zypper search` 语义。
Zypper 使用纯 URL。APT 使用一个在中间拆分的方案（“deb http://mirror/debian lenny/main”）。这种拆分允许有效地指定来自同一存储库的多个 URL，但有点笨拙。

openSUSE:RPM 糟透了

目录