來自紅帽的丹尼爾·馬赫 關於DNF 5套件管理器的開發開始，其中用Python實作的DNF邏輯將轉移到用C++編寫的libdnf函式庫中。 DNF 5 計劃在 Fedora 33 開發過程中於 2020 月開始測試，之後將於 2021 年 4 月添加到 Rawhide 存儲庫，並於 4 年 8 月取代 DNF XNUMX。DNF XNUMX 分支的維護將按原樣繼續進行用於紅帽企業Linux XNUMX。
值得注意的是，該專案已經達到了這樣的狀態：在不破壞 API/ABI 層級的兼容性的情況下，幾乎不可能繼續開發程式碼。 這主要是由於 PackageKit 的相關性以及在不更改「libhif」API 的情況下開發 libdnf 的可能性。 同時，儘管有意更改 API，但據說維持命令列介面和 API 層級的向後相容性是主要優先事項。
DNF 中對 Python API 的支援將被保留，但用 Python 編寫的業務邏輯將轉移到 libdnf (C++) 函式庫，這將確保發行版中套件管理器的操作相同。 開發將以C++ API為中心，Python API將基於其以包裝器的形式自動產生。
Go、Perl 和 的綁定
紅寶石。 C++ API 穩定後，將在其基礎上準備 C API，並將 rpm-ostree 轉移到該 API。 Python API 將被刪除並替換為 Python API。
DNF的核心功能將保留。 由於測試套件規模較大（約 1400 個測試），預計 API 返工不會影響最終用戶的命令列介面。 參數解析和輸出可能會略有變化，但這些變化將被詳細記錄。 精簡版 ，用於容器中，計劃實現DNF功能的子集；不考慮實現功能上的完全對等。
而不是 將建立一個新的 DBus 服務，提供用於管理軟體包和圖形應用程式更新的介面。 該服務計劃從頭開始開發，因此其創建可能需要大量時間。 PackageKit 最近沒有開發，並且由於失去相關性而自 2014 年以來一直處於維護模式。 隨著 Snaps 和 Flatpak 系統的進步，發行版對 PackageKit 失去了興趣，例如，它在構建中不再可用 。 套件管理的抽象層主要由本機 GNOME 和 KDE 應用程式控制中心提供，它們允許在個人使用者層級安裝 flatpak 套件。 用於取得已安裝軟體包清單的統一系統 API 不再像以前那麼有用。
來源： opennet.ru