LWN.net は、Fedora プロジェクトが最終的に DeltaRPMS のコンセプトを断念したと報じています。

2009年に、このプロジェクトは素晴らしいアイデアの実現に着手しました。yumアップデートを実行する際に、完全な.rpmファイルを送信するのではなく、バイナリの変更部分だけを送信すれば良いのではないか、というアイデアです。こうすることで、クライアント側ではOSが必要なもの（元のrpmファイルと差分）を再構築し、有効な更新済みrpmファイルを作成できるようになります。

すごい！帯域幅が制限されている人にとっては、これでエクスペリエンスが向上するはずです。

残念ながら、その技術はうまくいきませんでした。

まず、実際の体験は少々物足りなかった。まず、転送量は小さくなったとはいえ、初期のレイテンシとセットアップにはまだ時間がかかる。Yumはユーザーが持っているデータと必要なものを分析し、それをサーバーに送信し、応答を待ってからダウンロードを開始する。ネットワークの調子が悪いからこそメリットを期待していたとしても、結局はネットワークの調子が悪いという理由で、その代償の一部を支払わなければならない。

また、インターネットからダウンロードするデータは少量ですが、RPMの再構築にCPUとI/Oの負荷が増大します。小規模または低性能のシステムでは、RPM全体をダウンロードするよりも時間がかかる可能性があります。

LWN 経由で Fedora の幹部数名からのコメントを引用します。

転送されるファイルのサイズが時々わずかに減少するのを目にしましたが (これは確かに一部の人にとっては時々メリットになります)、トランザクションの合計経過時間は常に、元の rpm の再作成にかかる時間が、新しい rpm 全体をダウンロードするのにかかる時間を超えるため (私の環境では明らかにかなり高速なネットワーク プロバイダーを使用)、結局長くなりました。

しかし、主な問題は、FedoraによるこれらのDeltaRPMの管理が簡単ではないことです。

問題は、DeltaRPMは作成されても、ミラーに同期されるのはDeltaRPMが作成された日に作成されたアップデートの一部としてのみであるということです。翌日には、以前のDeltaRPMを使用せずに新しいディストリビューションアップデートが作成され、それがミラーにプッシュされます。Jonathan Dieter氏がバグレポートで指摘したように、この結果、DeltaRPMは1日しか利用できなくなります。「つまり、FedoraでDeltaRPMを最大限に活用するには、毎日アップデートするしかないということです。 」このようなやり方は「エンドユーザーにとってほとんど価値がない」と[FedoraのリーダーであるMatthew] Miller氏は述べています。

セキュリティ上の懸念もあります。

貴重な帯域幅リソースの節約は、今日よりも2009年の方が懸念事項でした。もちろん、世界には今でもより良い接続性が必要な地域が数多くありますが、DeltaRPMはもはや誰も不満を言わない問題を解決していたようです。