LWN.net报道称，Fedora 项目最终放弃了 DeltaRPMS 的概念。
早在 2009 年，该项目就开始研究一个很棒的想法：与其在用户执行 yum update 时发送完整的 .rpm 文件，为什么不只发送二进制更改呢？这样，在客户端，操作系统就可以重建它需要的内容（原始 rpm 文件 + 增量），从而生成有效的更新 rpm 文件。
太棒了！对于带宽受限的用户来说，这有望改善他们的体验。
可惜，这项技术最终失败了。
首先，实际体验略显不足。虽然传输的文件较小，但仍然存在初始延迟和设置问题。Yum 需要分析你已有的文件、你需要的文件，并将这些信息发送到服务器，等待响应，然后才能开始下载。如果你原本希望因为网络状况不佳而享受高速下载的便利，那么你仍然需要为此付出一部分代价，因为你的网络状况确实很差。
此外，虽然您从互联网下载的数据量较小，但重建 RPM 包会消耗更多的 CPU 和 I/O 资源。在配置较低或较弱的系统上，这可能会比下载完整的 RPM 包花费更多时间。
引用几位 Fedora 大佬通过 LWN 发表的话：
虽然我偶尔会看到传输的文件大小略有减少（这当然在某些时候对某些人来说是有利的），但交易的总耗时总是更高，因为重新创建原始 rpm 所需的时间超过了我直接下载完整新 rpm 所需的时间（尽管我使用的是速度相当快的网络提供商）。
但主要问题在于 Fedora 对这些 DeltaRPM 的管理并非易事。
问题在于，DeltaRPM 包虽然创建了，但只会在创建当天作为更新的一部分同步到镜像仓库；第二天，会创建一个新的发行版更新，该更新不使用之前的 DeltaRPM 包，并推送到镜像仓库。正如 Jonathan Dieter 在错误报告中指出的那样，最终结果是 DeltaRPM 包只能使用一天；“
这意味着在 Fedora 中充分利用 DeltaRPM 包的唯一方法是每天更新。” Fedora 负责人 Matthew Miller 表示，这种做法“对最终用户来说几乎没有任何价值”。
此外，还存在安全隐患。
2009 年，节省宝贵的带宽资源比现在更为重要。当然，世界上仍然有很多地方需要更好的网络连接，但 DeltaRPM 似乎解决的是一个如今已无人抱怨的问题。
