LWN：Fedora i686 的命运得到缓刑！

关注了就能看到更多这么棒的文章哦～

Fedora's i686 support gets a reprieve

By Joe Brockmeier
June 30, 2025
Gemini flash translation
https://lwn.net/Articles/1026917/

一项在 Fedora 44 发布时结束对 x86_64 架构上 32 位 x86 (i686) 应用程序支持的变更提案（change proposal），在遭遇强烈反对后已被撤回。根据该提案，这项变更可能会对玩家、编译器开发以及以 Fedora 为基础构建游戏发行版的 Bazzite 项目产生重大影响。虽然 i686 目前获得了暂缓，但问题依然存在：当很少有上游维护者（upstream maintainers）或志愿者打包者（volunteer packagers）关心该架构时，谁来保持必要的 i686 软件包正常运行呢？

如果你觉得似曾相识，请打断我

一些读者在得知 Fedora 正在讨论于 2025 年放弃 i686 支持时，可能会有一种似曾相识（/déjà vu/）的感觉；这个项目不是几年前就已经放弃了 i686 支持吗？答案是“是的，但并非完全放弃”。

Fedora 内核维护者 Justin Forbes 于 2017 年提议放弃 Fedora 的 i686 内核。这本会阻止 Fedora 27 版本提供 i686 内核，但一个x86特别兴趣小组（SIG）成立，负责维护该架构，并获得了确保其持续维护的机会。经过短暂的活跃期后，该 SIG 陷入休眠；i686 移除提案于 2019 年复活并获得 Fedora 31 版本的批准。从那时起，Fedora 停止为 i686 生产安装镜像、内核以及提供软件包仓库。

然而，该项目继续为 i686 构建软件包，这些软件包在 x86_64 仓库中提供“多架构支持”（multilib support）。这意味着用户不能再在 32 位 x86 系统上安装 Fedora，但可以继续在 x86_64 系统上运行 32 位应用程序。这对于像专有游戏或在 Wine 下运行的 Windows 软件等应用程序是必需的，因为为这些应用程序重新编译以支持 64 位是不可能的选项。

在 Fedora 37 中，该项目允许（并鼓励）软件包维护者停止为 i686 构建“叶子包”（leaf packages），而无需公布决定或提交跟踪错误报告。叶子包是指没有其他软件包依赖的包。如果维护者拥有的 i686 软件包是其他软件包的依赖项，他们仍需要遵循处理破坏性变更的程序。该变更提案包含了一个列表，列出了 230 多个软件包，这些软件包仍然是某些常见多架构使用场景的运行时依赖项，例如在 x86_64 上安装Steam客户端以进行游戏或使用 Wine。请注意，这并非所有可能必需的 i686 软件包的详尽列表，而只是作为运行时依赖项且明确不是叶子包的软件包的基础列表。

当前提案

6 月 24 日，Aoife Moloney 在 fedora-devel 邮件列表上宣布了放弃 32 位多架构支持并停止为 i686 构建软件包的变更提案。需要注意的是，最初向列表发布的通知错误地将其描述为 Fedora 43 的变更，而实际上它计划用于 Fedora 44 或更高版本。该提案的所有者——Kevin Fenzi、Fabio Alessandro Locati 和 Fabio Valentini——都是 Fedora 工程指导委员会（FESCo）的成员。当然，该委员会将是决定提案是否获得批准的机构。

该提案的目标是减轻软件包维护者的负担。提案指出，许多软件包的上游项目已放弃对 32 位架构的构建或运行支持，这要求维护者投入额外工作以确保这些软件包能够继续为 i686 构建。

i686 软件包的构建也给 Fedora 的发布工程团队和基础设施带来了负担；放弃 32 位库将使团队能够摆脱为适应 i686 所需的“脆弱的启发式规则和约定”，同时减轻 x86_64 构建系统交叉编译大约 10,000 个 i686 软件包的负载。

用户也将从放弃 i686 中获得一个小小的益处。x86_64 仓库的元数据会因为没有这些软件包而变得更小；反过来，这将加快下载速度和 DNF 依赖解析。

该提案包含三个步骤；第一个，也是在需要时最容易撤销的步骤，是停止在 x86_64 仓库中包含 i686 软件包。第二个步骤，不再为 i686 构建软件包，被描述为基本上不可逆：“撤销这些变更将需要重新引导（re-bootstrapping）该架构，这很难证明其合理性。”Fedora 版本通常由上一个版本构建——新架构必须通过交叉编译足够的软件包来为该平台编译完整版本进行引导。最后，还需要有一种机制，以便在升级时从 Fedora 系统中移除 i686 软件包。

反响

Jakub Jelinek 表示，禁用 i686 将对打包编译器造成问题，例如 GCC，它需要一些 i686 库来支持生成 32 位模式（-m32 ）代码。i686 软件包的完全缺失也将影响开发其他编译器和工具链的开发者；这可能导致用户从 Fedora 迁移出去。他建议减少正在构建的 i686 软件包数量，并取消 i686 软件包的文档，这样就不再需要构建 32 位 TeX 和其他用于生成文档的工具。但是，他说：“将集合缩小到零将不利于发行版。”

Daniel P. Berrangé 指出，Fedora 只发布了少数几个由 GCC、GNU Binutils 等工具支持的主机架构，因此这不可能是 i686 特有的问题。Fedora 已经为其他不支持的架构提供了交叉编译器构建，那么为 i686 提供一个交叉编译器构建难道不够吗？

Jelinek 回复道，在 Fedora 上为不支持的平台开发 GCC “非常痛苦”，而且对于作为 GCC 少数几个主要架构之一的 i686-linux 来说，这肯定是不够的：

我们中有些人每天都会在 x86_64-linux 和 i686-linux（目前是运行 64 位内核但有 i686 RPM 包的 Fedora）上进行引导/回归测试，以确保代码的 32 位和 64 位兼容性等。否则，这将不再可能或变得困难得多。

Adam Williamson 追问 Jelinek 解释为什么 32 位开发在这一点上仍然重要。“我期待听到‘是的，GCC 仍然关心 32 位，因为<请在此处插入充分的理由>’。我只是想把它写下来。”Jelinek 强调了 32 位的重要性，但 Stephen Smoogen 用他最近在嵌入式硬件方面的工作给出了一个具体例子：

过去四年在 Fedora 之外的工作让我更加确信，计算机世界并非全是 64 位。从标准汽车中的 900 台微型计算机，到洗衣机中的大约 10 台，大部分硬件都是 16 位和 32 位的。普通的家用电脑至少有 4 个 32 位 CPU 和几个 16 位 CPU，它们在你的 64 位处理器和 GPU 的幕后工作。英特尔在这个 32 位世界中仍然被广泛使用，而主要使用的编译器是 GCC。

他说，由于许多红帽（Red Hat）开发者使用 Fedora 来支持该生态系统，这意味着 Fedora 上的构建链问题比其他操作系统得到更多关注。如果这些开发者不得不转向其他操作系统，就意味着对 Fedora 问题的关注会减少。

参与讨论的大多数人似乎都认为当前的 i686 状况难以为继，但尚未完全准备好将发行版中的 i686 支持彻底清除。David Airlie 回复说，他更倾向于从列出具有 i686 依赖关系的软件包开始，然后放弃其余的。他建议，提供Mesa 3D 图形支持的软件包及其依赖项将是一个很好的开始。在后续回复中，他确定了需要构建超过 150 个软件包才能支持 Mesa。

Steam 和 Bazzite

讨论的很大一部分集中在运行 Steam 上，它不是一个开源应用程序，而且提供它的公司 Valve 也没有为 Fedora 打包。然而，它可以从RPM Fusion仓库安装。

Berrangé 表示，Steam 是否运行并非 Fedora 关心的问题。他说，它的需求与项目的使命和基础不符，因此不应该对是否放弃 i686 软件包的决定产生重大影响。而 Michal Schorm 不同意：

Fedora 重视道德选择而非简单选择。但这并不意味着我们不应该关心并说“那不是我们的问题”。

这是我们的问题。如果我们没有充分的理由，就让大量用户无法升级他们最喜欢的软件，我们将迫使他们离开，而且他们将永远不会回来。

他建议与 Valve 讨论情况，看看他们能做些什么来保持 Fedora 的游戏玩家基础活跃。他说，这可能不会成功，但这比“我们不在乎”是一个更好的理由。

当 Canonical 在 2019 年计划放弃 i686 软件包时，它受到了足够的社区反对，以至于它修订了其计划，并为 Ubuntu 版本构建了“精选的 32 位 i386 软件包”，如Ubuntu 维基上所述。

Valentini 表示，在 Fedora 上运行 Steam 一个被忽视的选项是使用 Flatpak，它已经包含了必要的 32 位库。他说，他多年来一直在使用 Steam Flatpak 进行游戏，并且没有遇到任何 Flatpak 特有的问题。不过，无论如何，他表示，对 i686 的支持迟早会结束：

是的，有些东西会停止工作。但我希望我们能为大多数用例提供解决方案和/或变通方法。

现在就开始规划 i686 软件包的移除，总比等到（例如 CPython 等）基础包停止支持 32 位架构时我们才需要仓促适应要好。

Noel Miller 表示，该提案将影响像 Bazzite 这样的下游项目，Bazzite 是一个Universal Blue项目，它从 Fedora 软件包构建基于镜像的操作系统以用于特定用例。LWN 在 2023 年报道的 Bluefin 也是一个 Universal Blue 项目。

Bazzite 需要 Steam 的原生安装而非 Flatpak，以便Gamescope Wayland 合成器能够正常工作。Ashe Hutchins 解释说，这是因为许多 Bazzite 用户在掌上游戏电脑（例如Steam Deck）上运行该发行版，并且希望模拟 Steam 的游戏模式。虽然曾尝试使用 Flatpak 和 Podman 容器解决方案来替代原生安装，但这些尝试都遇到了无法克服的问题：

Gamescope 是一个微型合成器（microcompositor）。细节虽然有些复杂，但它基本上可以作为三种类型的合成器：嵌套合成器（Nested compositor）——在当前桌面环境之上运行；嵌入式合成器（Embedded compositor）——嵌入到特定应用程序中；会话合成器（Session compositor）——本质上像桌面环境一样运行。Gamescope 的 Flatpak 版本可以提供前两种功能。最后一种，即 bazzite-deck 等类控制台体验所提供的功能，则无法实现。

我给 Bazzite 的首席开发者 Kyle Gospodnetich 发送了电子邮件，询问 Bazzite 团队在提案宣布之前是否曾被接触过，以及如果提案获得批准，该项目将有什么计划。他说，他们事先没有被接触过，所以“现在是我们沟通我们的需求和用例的机会”。他指出，一些 Fedora 贡献者并没有意识到 Flatpak 不适用于 Bazzite 的用例。

Gospodnetich 同意 Fedora 没有理由构建如此多的 32 位软件包，但为了传统兼容性，仍然需要一些 32 位软件包。“有 30 年的 PC 游戏永远不会获得更新，而且 Bazzite 使用 Steam 提供的功能在容器中无法工作。”他说，如果 Fedora 决定完全放弃 32 位软件包，Bazzite 没有应急计划。

从传统意义上讲，Bazzite 并非一个发行版，我们的构建流程无法处理这个问题，我们也没有足够的人力来完成构建。Steam 和 Wine 所需的软件包需要与 Fedora 保持同步，并且可能需要应用更改才能长期保持 32 位构建，这意味着版本会漂移，并且我们有发布损坏构建的风险，除非我们也能在出现不匹配时暂停/阻止构建。

如果 Bazzite 所依赖的 32 位软件包消失，那么终止 Bazzite 项目会更容易、更好。然而，他认为正在讨论的关于构建 32 位软件包子集的一些选项非常优秀，并且“可以达成一个对所有人来说都更好的中间方案”。Gospodnetich 补充说，他对 Fedora 这个项目充满信心，“没有他们，我们都不会在这里。”

i686 会影响到具体的人

这场讨论才刚刚开始几天，还有时间提出可能避免 i686 在 Fedora 上某些用例中走向终结的提案。然而，核心问题是，按照 Fedora 目前的方式维持 i686 运行，对于志愿者打包者来说是一项未拨款的任务（unfunded mandate）。Berrangé 表示：

这是 Fedora 定期出现的非同寻常的变更提案之一，不采纳它，事实上就等同于有意识地决定强制志愿者维护者继续从事许多人认为不受欢迎且技术上没有前途的工作。

将问题推迟几个版本并不能解决问题，他对 Valve 现在会“突然决定做些不同寻常的事情”几乎不抱希望。他说，理想情况下，那些仍然关心 i686 的人应该制定一个支持它的策略，同时避免目前它所带来的跨发行版和构建基础设施负担。一个完整的解决方案不必在 Fedora 44 发布前出现，但“我们至少需要朝着一个比现状更可持续的解决方案迈出一步”。

新任 Fedora 项目负责人 Jef Spaleta 表示，他认为当前的提案是一种必要的激励，旨在让“适当的人制定出一个破坏性更小的可行计划”。在后续评论中，他说 Fedora 必须找到一种方法将 i686 工作“分离出来，让那些背负负担的人可以放下，而关心它的人则可以接手”。如果这没有发生，那么项目可能不得不接受完全放弃 i686。

一些评论者不满该提案似乎是一种强迫他人站出来接管 i686 维护的方式。Claire Robsahm 表示：

我不同意将这项提案用作“达摩克利斯之剑”（Sword of Damocles），以激励其他提案的出现。这意味着像我这样的局外人——玩家和开发者——会将此视为“默认”结果，这将给 Fedora 作为可靠的游戏和开发者平台的长期未来带来不确定性。

Miller 表示同意，并指出 Fedora 作为一款用于玩游戏和开发游戏的发行版，一直以来都获得了很大的势头；这项提案“已经对 Fedora（以及延伸到 Bazzite）造成了品牌损害和用户信心丧失”。

撤回

经过大量讨论——包括 Fedora 的 Discourse 论坛上的400 条评论——Valentini 于 6 月 28 日撤回了该提案，并表示他期待在反提案准备就绪时能看到它们。

目前，那些依赖 Fedora 上多架构支持（multilib support）的用户可以松一口气了，但问题依然存在。维护 Fedora i686 软件包的负担，主要由那些对这项工作不感兴趣或未从中受益的人承担。而那些确实受益于这项工作的用户和商业实体，到目前为止尚未站出来肩负起这份负担。这种情况是不可持续的，也不太可能无限期地得到支持。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～