由於 Yum 中許多長期存在的問題仍未得到解決，因此 Yum 包管理器已被 DNF 包管理器取代。這些問題包括效能差、記憶體占用過多、依賴解析速度變慢等。
DNF 使用 libsolv 進行依賴解析，由 SUSE 開發和維護，旨在提高效能。
Yum 主要是用 Python 編寫的，它有自己的應對依賴解析的方法。它的 API 沒有完整的文件，它的擴充套件系統只允許 Python 外掛。
Yum 是 RPM 的前端工具，它管理依賴關係和資源庫，然後使用 RPM 來安裝、下載和刪除包。
為什麼他們要建立一個新的工具，而不是修復現有的問題呢？
Ales Kozamblak 解釋說，這個修復在技術上是不可行的，而且 Yum 團隊還沒有準備好立即接受修改。
另外，最大的挑戰是，Yum 有 56000 行程式碼，但 DNF 只有 29000 行程式碼。
所以除了分叉，沒有辦法解決。
不過 Yum 的執行情況還算可以。
| 編號 | DNF（Dandified YUM） | YUM（Yellowdog Updater, Modified） |
|---|---|---|
| 1 | DNF 使用 libsolv 來解析依賴關係，由 SUSE 開發和維護 | YUM 使用公開的 API 來解析依賴關係 |
| 2 | API 有完整的文件 | API 沒有完整的文件 |
| 3 | 由 C、C++、Python 編寫的 | 只用 Python 編寫 |
| 4 | DNF 目前在 Fedora、RHEL 8、CentOS 8、OEL 8 和 Mageia 6/7 中使用 | YUM 目前在 RHEL 6/7、CentOS 6/7、OEL 6/7 中使用 |
| 5 | DNF 支援各種擴充套件 | Yum 只支援基於 Python 的擴充套件 |
| 6 | API 有良好的文件，因此很容易建立新的功能 | 因為 API 沒有正確的文件化，所以建立新功能非常困難 |
| 7 | DNF 在同步儲存庫的後設資料時，使用的記憶體較少 | 在同步儲存庫的後設資料時，YUM 使用了過多的記憶體 |
| 8 | DNF 使用滿足性演算法來解決依賴關係解析（它是用字典的方法來儲存和檢索包和依賴資訊） | 由於使用公開 API 的原因，Yum 依賴性解析變得遲鈍 |
| 9 | 從記憶體使用量和版本庫後設資料的依賴性解析來看，效能都不錯 | 總的來說，在很多因素的影響下，表現不佳 |
| 10 | DNF 更新：在 DNF 更新過程中，如果包中包含不相關的依賴，則不會更新 | YUM 將在沒有驗證的情況下更新軟體包 |
| 11 | 如果啟用的儲存庫沒有響應，DNF 將跳過它，並繼續使用可用的儲存庫處理事務 | 如果有儲存庫不可用，YUM 會立即停止 |
| 12 | dnf update 和 dnf upgrade 是等價的 | 在 Yum 中則不同 |
| 13 | 安裝包的依賴關係不更新 | Yum 為這種行為提供了一個選項 |
| 14 | 清理刪除的包：當刪除一個包時，DNF 會自動刪除任何沒有被使用者明確安裝的依賴包 | Yum 不會這樣做 |
| 15 | 儲存庫快取更新計劃：預設情況下，系統啟動後 10 分鐘後，DNF 每小時會對設定的儲存庫檢查一次更新。這個動作由系統定時器單元 dnf-makecache.timer 控制 | Yum 也會這樣做 |
| 16 | 核心包不受 DNF 保護。不像 Yum，你可以刪除所有的核心包，包括執行中的核心包 | Yum 不允許你刪除執行中的核心 |
| 17 | libsolv：用於解包和讀取資源庫。hawkey: 為 libsolv 提供簡化的 C 和 Python API 庫。librepo: 提供 C 和 Python（類似 libcURL）API 的庫，用於下載 Linux 儲存庫後設資料和軟體包。libcomps: 是 yum.comps 庫的替代品。它是用純 C 語言編寫的庫，有 Python 2 和 Python 3 的系結。 | Yum 不使用單獨的庫來執行這些功能 |
| 18 | DNF 包含 29000 行程式碼 | Yum 包含 56000 行程式碼 |
| 19 | DNF 由 Ales Kozumplik 開發 | YUM 由 Zdenek Pavlas、Jan Silhan 和團隊成員開發 |