Fedora's engineering steering committee has approved the move to the RPM v6 package format for Fedora 46, while rejecting a proposed ThinLTO compiler flag for the release — a pair of decisions that together sketch out where the distribution is placing its bets ahead of next year's launch.
According to Phoronix, the RPM v6 format has been signed off for Fedora 46, while the ThinLTO flag proposal did not clear the same bar. Fedora 45 shipped last week, and attention inside the project has shifted quickly to Fedora 46, which is expected to debut by the end of April 2027.
What the two decisions signal
Taken separately, either decision would be a routine item on a release-planning agenda. Read together, they suggest Fedora is prioritising foundational plumbing over headline-grabbing performance work for this cycle.
RPM v6 is the more consequential of the pair. The RPM package format underpins not just Fedora but a wide family of downstream distributions and third-party tooling, so a format-version bump is ecosystem news rather than a Fedora-only news item. Any organisation that builds, repacks, signs, mirrors, or audits RPM artifacts — whether maintaining an internal repository, running configuration-management pipelines against package metadata, or feeding packages into vulnerability-scanning systems — will eventually need to confirm that its toolchain handles the newer format correctly. Fedora's decision effectively sets a schedule that the broader RPM ecosystem has to plan around.
ThinLTO, by contrast, is a link-time optimisation technique from the LLVM toolchain that splits modules across compilation units to enable more parallelised and incremental optimisation. It is the kind of change that tends to show up as benchmark deltas rather than user-visible features. The proposal's rejection appears to reflect a judgement about timing and risk rather than a verdict on the technology itself; Phoronix's reporting confirms the outcome but, based on the material available at the time of writing, does not record the committee's specific objections in detail. That framing — a capability deferred rather than dismissed — is interpretation, not a documented rationale.
For anyone tracking how Fedora handles rejected work, it is generally understood within the project that proposals declined for one release cycle frequently resurface in a revised form for a later one. Whether that applies to this ThinLTO flag is, at this point, speculation.
Why it matters beyond Fedora
Fedora's release decisions ripple outward. Enterprise distributions in the Red Hat lineage, as well as community rebuilds such as AlmaLinux and Rocky Linux, follow Fedora's technical direction closely, even where adoption timelines differ. Teams running internal package mirrors or staging repositories against those downstreams have a natural interest in how the RPM format transition is paced — an April 2027 Fedora 46 debut gives tooling maintainers a concrete window to test package-handling assumptions well before any downstream rebuild picks the change up.
That testing window is the practical takeaway: packaging pipelines, repository tooling, and package-auditing utilities should be validated against RPM v6 expectations sooner rather than later, rather than after a downstream rebase lands.
Fedora 46's end-of-April target leaves just under six months of development time, during which the RPM v6 integration will be the piece to watch — and the ThinLTO question one that may yet return to the committee's agenda.
Source: Phoronix, "RPM v6 Format Approved For Fedora 46, ThinLTO Flag Rejected".
Fedora 工程指導委員會已批准在 Fedora 46 採用 RPM v6 封裝格式，同時否決了為該版本加入 ThinLTO 編譯旗標的建議——這兩項決定共同勾勒出發行版在明年正式推出前的策略重心。
據 Phoronix 報道，RPM v6 格式已獲批用於 Fedora 46，而 ThinLTO 旗標建議則未能通過同一標準。Fedora 45 已於上週推出，項目內部的焦點亦已迅速轉向 Fedora 46，該版本預計於 2027 年 4 月底前首度亮相。
兩項決定所傳遞的訊號
單獨來看，任何一項決定都只是發行計劃議程上的例行事項。但放在一起解讀，則顯示 Fedora 在本輪開發周期中，優先處理的是基礎架構的鋪墊，而非搶眼的效能改進。
RPM v6 是兩者之中影響較為深遠的一項。RPM 封裝格式不僅支撐 Fedora 本身，更涵蓋廣泛的下游發行版及第三方工具生態，因此格式版本升級屬於整個生態圈的大事，而非 Fedora 一己的新聞。任何建置、重新封裝、簽署、建立 mirror 或審核 RPM artefact 的機構——不論是維護內部 repository、針對封裝 metadata 運行組態管理 pipeline，還是將封裝輸入漏洞掃描系統——最終都需要確認其 toolchain 能正確處理較新的格式。Fedora 的決定實質上為整個 RPM 生態圈訂下了一個必須據此規劃的時間表。
相較之下，ThinLTO 是 LLVM toolchain 中的一項連結時最佳化（link-time optimisation）技術，透過將 module 分拆至不同 compilation unit，以實現更高程度的平行化及漸進式最佳化。這類改動往往只會反映在基準測試的數值差異上，而非用戶可見的功能。該建議被否決，看來是出於對時機與風險的判斷，而非對技術本身的否定；Phoronix 的報道確認了有關結果，但根據撰稿時可得的資料，並未詳細記錄委員會的具體反對意見。至於將此事定性為「一項功能被延後而非被否決」，則屬詮釋，並非有文件記載的理由。
對於關注 Fedora 如何處理被拒方案的人士而言，項目內部普遍理解，某個發行周期被否決的建議，日後往往會以修訂形式在另一個周期重新提出。至於這項 ThinLTO 旗標是否適用此規律，目前仍屬推測。
為何此事的影響不限於 Fedora
Fedora 的發行決定會向外擴散。Red Hat 譜系的企業級發行版，以及 AlmaLinux、Rocky Linux 等社群 rebuild 項目，均密切跟隨 Fedora 的技術方向，即使實際採用的時間表各有不同。在這些下游版本上運行內部封裝 mirror 或 staging repository 的團隊，自然關注 RPM 格式過渡的節奏——Fedora 46 於 2027 年 4 月底推出，為工具維護者提供了一個具體的測試窗口，可在任何下游 rebuild 採納該變更之前，及早驗證封裝處理的各項假設。
這個測試窗口正是務實的重點所在：封裝 pipeline、repository 工具及封裝審核工具，應盡早按照 RPM v6 的預期進行驗證，而非等到下游 rebase 落地之後才著手。
Fedora 46 以 4 月底為目標，僅餘不足六個月的開發時間，期間 RPM v6 的整合將是需要密切留意的重點——而 ThinLTO 的問題，亦可能日後重歸委員會議程。
資料來源：Phoronix，"RPM v6 Format Approved For Fedora 46, ThinLTO Flag Rejected"。