Fedora 上的 dnf，悄悄換了一副骨架

在 Fedora 41 之後的系統裡敲 dnf，實際執行的多半已經不是當年那個用 Python 寫的版本。DNF5 是同一個專案的重寫版，改用 C++ 實作，從 Fedora 41 起成為預設的套件管理器，dnf 這道命令如今只是一個指向它的符號連結。專案由 rpm 軟體管理組織維護，授權條款為 GPL 第二代及其後續版本。值得讀一讀的原因不在「有人重寫了一支工具」——那種事天天發生——而在於這次重寫對準的正是使用者真的會感受到的部位：裝起來佔多少空間、一道命令啟動要等多久、一次查詢多久才回話。

拿掉 Python，省下來的是體積與啟動開銷

舊版 dnf 建立在 Python 之上，每次呼叫都得先拉起直譯器，再載入一整疊模組，才輪到真正要做的事。DNF5 把這些邏輯搬進編譯後的函式庫，命令列工具本身不再依賴 Python。依 Fedora 官方發布說明的數字，在一個空容器裡安裝這整套工具，體積比原本小約 60%。查詢類的收益更直接：repoquery 這種列出倉庫可用套件的命令，處理速度約為原來的兩倍，列依賴、解析長參數列表的等待時間也跟著縮短。一個月跑一次的話這只是細節；若是一小時被腳本叫上一百次，它決定的是哪些做法還算可行。

具體改了哪些地方

三件工具合而為一。原本的 dnf、microdnf 與圖形化後端各自維護快取，中繼資料被重複存了好幾份；換成 dnf5 與它的背景服務之後共用同一份，這層多餘就抹掉了。外掛不再單獨打包，改與主程式一起安裝，升級後版本對不上的機會小得多。管理套件、操作倉庫、求解依賴這三類介面，收斂進同一個元件，腳本語言的綁定統一由一個工具產生，命名風格也一併統一。輸出與說明也重做過：交易表格交代的資訊更細，腳本片段那些冗長的輸出按套件名重導進記錄檔，每道命令都配了獨立的手冊，Shell 的補齊同樣做了加強。

遷移時值得留意的兩件事

一是歷史資料庫彼此不相通。dnf 與 dnf5 各記各的交易歷史，格式也不同，在舊工具裡裝過的套件，在新的一側看不到那次操作。DNF5 第一次執行交易時，會試著讀取舊的歷史並轉換系統狀態，盡量保住「這個套件當初是當依賴裝上的」這類資訊，免得日後把依賴套件當成使用者主動安裝的軟體，就此錯過回收的機會。二是企業發行版還在用舊版：商用那支的第九代、它的兩個社群重建版，以及第十代，目前預設仍為原本的 dnf，DNF5 還沒在這些系統上接手。截至 2026 年 9 月，最新發布的是 5.4。對一般 Fedora 使用者來說，直接敲 dnf 就好；想明確區分時再寫 dnf5。

為了壓低遷移成本，常用命令與選項都保留了相容別名，原本寫順手的用法基本照舊。python3-dnf 與 libdnf 兩套舊函式庫也還留在系統裡，可以與 DNF5 並存，只是不建議兩邊交替改動已安裝的軟體，因為系統狀態並不共用。

誰需要關心它

如果只在一台 Fedora 桌面上偶爾裝裝軟體，感受大概只是「命令回得快了一點」。真正受益的是把 Fedora 當基礎映像用的場景：容器裡少裝一套 Python 執行環境，映像就小一圈；伺服器上反覆跑 repoquery 做資產清點，翻倍的查詢速度累積起來是紮實的時間。它的價值不在多出幾個開關，而在把套件管理器從腳本語言搬到編譯語言：體積更小、查詢更快、快取不再重複存一份。Fedora 41 之後的使用者已經在用它，企業那一系還得再等一陣。