Gentoo 的 Chromium 包走向终结

# Gentoo 的 Chromium 包最后的葬礼 来源：https://lwn.net/SubscriberLink/1097760/2be4d9e3eeb59039/ > ### 欢迎来到 LWN\.net 以下仅限订阅者的内容由 LWN 订阅者提供给你。数千名订阅者依靠 LWN 获取 Linux 和自由软件社区的最佳新闻。如果你喜欢这篇文章，请考虑订阅 LWN (https://lwn.net/subscribe/)。感谢访问 LWN\.net\! Chromium (https://www.chromium.org/Home/) 是 Google Chrome 网页浏览器的开源上游项目，也是许多 Linux 用户的首选浏览器。它还赢得了一个名声：对 Linux 发行版来说，打包和构建它是件棘手的事 (https://lwn.net/Articles/619158/)：Chromium 的构建系统十分复杂，项目捆绑了大量依赖项，而且发布非常频繁。所有这些因素，加上用户的抱怨，最终让 Gentoo Chromium 包 (https://packages.gentoo.org/packages/www-client/chromium) 的维护者放弃了维持这个包的努力。 Gentoo 的重点是让用户使用 Portage (https://wiki.gentoo.org/wiki/Handbook:X86/Working/Portage) 软件管理工具从源码构建自己的软件。Gentoo 的打包者会创建 ebuild (https://wiki.gentoo.org/wiki/Ebuild) 文件，这些文件是用类似 Bash 的语法编写的文本文件，包含 Portage 构建软件所需的信息。然后用户自己使用 `emerge` (https://wiki.gentoo.org/wiki/Emerge) 构建软件包，它是 Portage 的命令行接口。最近的一份 Chromium ebuild (https://github.com/gentoo-mirror/gentoo/blob/stable/www-client/chromium/chromium-151.0.7922.169-r1.ebuild) 就体现了这个包的复杂程度。 Gentoo 确实通过其 Binhost (https://wiki.gentoo.org/wiki/Project:Binhost) 项目为部分软件提供预构建的二进制包。不过，从源码构建可以让用户通过声明 USE 变量 (https://wiki.gentoo.org/wiki/USE_flag) 来灵活设置编译期选项或更改软件包的配置。例如，用户可能希望指定将哪些可选库与软件包链接，或者是否安装随附的文档。就 Chromium 而言，用户可能会启用 `-bundled-toolchain` USE 变量（它告诉 Portage*不*使用捆绑的工具链），以便使用系统自带的 Clang 版本编译 Chromium，而不是使用上游项目捆绑的版本 (https://chromium.googlesource.com/chromium/src/+/90.0.4430.72/docs/clang_sheriffing.md)。对于 x86-64 系统上的 Gentoo 用户来说这是可选的，但对于其他架构上的用户则是必需的，因为 Chromium 的捆绑工具链只为 x86-64 提供。 值得一提的是，由于在使用专有编解码器构建该包时遇到问题，Gentoo 目前不提供 Chromium 的二进制包。 #### 最后的葬礼 包括 Arch Linux、Debian 和 Fedora 在内的许多发行版使用"孤儿包"一词来指代被维护者遗弃的软件包；开发者会宣布该包已成为孤儿包，其他贡献者则有机会在愿意的情况下认领维护权。Gentoo 的术语则更具戏剧性：包维护者会在 gentoo-dev-announce 邮件列表上宣布某个包的"最后的葬礼"，以告知项目该包将不再维护，并借此机会让其他开发者认领维护权。 开发者宣布最后的葬礼之后，该包的 ebuild 会在 Gentoo 的 ebuild 仓库 (https://wiki.gentoo.org/wiki/Knowledge_Base:Masking_a_package) (https://wiki.gentoo.org/wiki/Ebuild_repository#The_Gentoo_ebuild_repository) 中被屏蔽 (masked)，以确保用户不会误装已经不再维护的包。已经安装了该包并尝试升级的用户会收到它已被屏蔽的警告。Chromium 包维护者 Sam James 于 9 月 24 日在 Roman Žilka 提交的一份 bug 报告 (https://bugs.gentoo.org/982204) 中经过长时间的讨论后，宣布了 Chromium 包的最后的葬礼 (https://lwn.net/ml/all/87ld8rb0p1.fsf%40gentoo.org/)。 9 月 9 日，Žilka 曾抱怨 (https://bugs.gentoo.org/982204#c0) 最新稳定版的 Chromium ebuild 已经过时： > 最新稳定的 www-client/chromium（以及 google-chrome，可能还有其他包）是 151.0.7922.169，其中包含 602 个各种严重程度的已知漏洞，堪称灾难。对于如此重要的软件包，必须有人采取措施，防止这种情况反复发生。 他还在 bug 报告中附上了一份更新版本的 Chromium ebuild (https://982204.bugs.gentoo.org/attachment.cgi?id=970220)，但指出如果用户尝试使用 `-bundled-toolchain` USE 变量编译 Chromium，这份 ebuild 将无法工作。 James 回复 (https://bugs.gentoo.org/982204#c5) 说："Chromium 作为源码包维护起来简直糟糕透顶。它绝对是 Gentoo 中最消耗维护者的包。" 他说抱怨维护状况无助于解决问题，并补充说多年来维护者们曾多次差点给 Chromium 宣布最后的葬礼，因为让它保持最新实在太困难了。他还提到自己之前就向 Žilka 说明过这一点，并表示如果对方愿意协助维护这个包，他会非常欢迎。 事实上，Žilka 在 8 月份就曾提交过一份类似的 bug (https://bugs.gentoo.org/980389)，抱怨 Chromium ebuild 中存在大量漏洞；James 当时回复 (https://bugs.gentoo.org/980389#c1) 说这个包一直很难维护，"现在他们又把 Go 加成了依赖项"。在此之前，Žilka 曾出现在 Matt Jolly 关于 Chromium 漏洞提交的 bug 报告 (https://bugs.gentoo.org/show_bug.cgi?id=CVE-2025-14372) 中，抱怨 (https://bugs.gentoo.org/show_bug.cgi?id=CVE-2025-14372#c4)："更新流程需要修正，这样在如此关键的软件包上就不会再发生这类事件了！" Jolly 回复 (https://bugs.gentoo.org/show_bug.cgi?id=CVE-2025-14372#c7) 说，维护者们是一个志愿者团队，都在尽自己最大的努力，但"构建失败、人为因素（'我把 bug 指派错了，而自动化流程没有捕获到它'），以及我自己有限的空闲时间是造成延迟的最大原因"。他说，改变这种状况的最佳方式就是 Žilka 自愿伸出援手。 #### 反复尝试 Gentoo 有各种各样的第三方仓库，称为 overlay (https://wiki.gentoo.org/wiki/Project:Overlays)，它们提供额外的和替代的 ebuild。9 月 11 日，Nick Reale 说 (https://bugs.gentoo.org/982204#c11) 他曾尝试过 Bentoo (https://obentoo.org/v/v3e/) 和 Fireburn (https://github.com/FireBurn/Overlay) overlay 中更新版本的 Chromium ebuild，但两个都没能让它工作起来。几天后，他报告 (https://bugs.gentoo.org/982204#c16) 说使用 Bentoo 的 ebuild 和一组特定的 USE 变量终于成功了。Reale 和 François Valenduc 随后就各自如何通过其他 ebuild 在 Gentoo 上编译更新版本的 Chromium 进行了进一步的讨论。9 月 18 日，Valenduc 评论 (https://bugs.gentoo.org/982204#c20) 说 Chromium 的 153.0.8010.47 版本已经发布，而且该版本已经在 Arch Linux、openSUSE、SUSE 和 Ubuntu 上可用。"尽管这里已经提出了那么多方案，我们却仍在等待 Gentoo。" James 回复 (https://bugs.gentoo.org/982204#c21) 说，维护者们还没有机会排查 Chromium 包的问题。他说，随 bug 报告提交的补丁和 ebuild "很有用，也很感谢，但事情并不是把东西拿过来提交一下那么简单"。他说，如果维护者们没有测试过这些 ebuild 就提交，结果在用户系统上出了问题，用户会抱怨的。 > 这事该做的时候自然会做，但如果没有人愿意以处理这类事务所需要的方式来处理它（这远不只是附上 ebuild 那么简单），那它被宣布最后的葬礼的可能性反而更大。 Valenduc 说 (https://bugs.gentoo.org/982204#c22) 他没有能力维护这个包，"但把 bentoo overlay 中的 ebuild 拿来用并没有那么难\[……\]只是看到 Gentoo 一直没有更新，实在令人沮丧。" James 回复 (https://bugs.gentoo.org/982204#c23) 说，ebuild 能在 Valenduc 那里工作，并不代表它所有的 USE 变量都正常。他还说，没有人向 Gentoo 的 ebuild 提交过补丁，这意味着维护者们需要通过对比 ebuild 之间的差异来逆向工程这些改动，搞清楚到底改了什么。"这些工作量绝不小，虽然有一个现成的 ebuild 作为起点对此有帮助，但并不意味着可以直接 `git add` 然后 `git commit` 再 `git push` 就完事了。" Valenduc 承认 (https://bugs.gentoo.org/982204#c24) 他无法测试所有可能的 USE 变量，因为在他的笔记本上编译 Chromium 需要 15 到 16 个小时。 9 月 24 日，Žilka 评论 (https://bugs.gentoo.org/982204#c30)："这太荒谬了"。几分钟后，James 回复 (https://bugs.gentoo.org/982204#c31) "好吧，那就这样"，并为该包发布了最后的葬礼 (https://bugs.gentoo.org/982204#c32)。 #### 我们能留住它吗？ Maciej S. Szmigiero 询问 (https://bugs.gentoo.org/982204#c35) 是否有可能把 ebuild 保留在 Gentoo 的仓库中，只是宣布它以"尽力而为"的水平维护。"移除一个可构建、可打补丁的 Chromium 对 Gentoo 桌面系统来说是巨大的损失。" James 说 (https://bugs.gentoo.org/982204#c36) 他认为这不可能。他已经解释过 Chromium 是由志愿者维护的，而这个解释并没有被接受。 他说，人们可以自由地在其他仓库中维护 ebuild，但那意味着他们必须自己承担工作，或者接受由别人以较低的标准来完成。他指出，讨论中有人引用了 Bentoo overlay 的 ebuild，但那些 ebuild 的创建过程似乎"高度自动化"，遗漏了 Gentoo 版本中的一些修复。"复制 ebuild 这种做法行得通，直到它行不通为止。" James 补充说，在 10 月 24 日最后的葬礼期限结束之前，仍然可以有人接手 Chromium 包，或者这个包将来有可能被恢复。不过，除非有可持续维护的计划，否则他不希望看到这种情况。"由于上游更新频繁，Chromium 在 Gentoo 的历史一直是在消耗维护者，不过这个 bug 里的某些内容对激励也毫无帮助。" Matt Whitlock 想知道 (https://bugs.gentoo.org/982204#c42) 能否通过削减 Chromium 的大部分 USE 变量，或者让维护者们不再将第三方库解绑，来减轻开发者倦怠的因素。 > 简单来说，我想问的是：我们能不能放弃 _所有_ 习惯了在 www-client/chromium 中享有的灵活性，换取一个真正可维护的、但仍然使用非以不透明二进制形式分发的工具链从源码构建的包？ 他后来又补充 (https://bugs.gentoo.org/982204#c46) 说，部分问题在于上游项目的开发者"没有禁用任何他们所谓的'可选'功能来测试构建"。这就把责任留给了下游的软件包维护者。"对于 Chromium 来说，在上游长期忽视的情况下让所有这些开关都正常工作，是一项艰巨得几乎无法完成的任务。" #### 复杂性 James 说 (https://bugs.gentoo.org/982204#c47) 这是个好问题，但 Chromium 最近复杂性增加的部分原因是加入了 Rust 和 Go 依赖。打包者们不得不费尽周折来确保 Go 的构建不需要网络访问——Gentoo 的 ebuild 明令禁止网络访问——但这并不是唯一的问题。他说，Google 的开发者们似乎一直在使用实验性的 Rust 功能，这些功能在新版本中会崩溃。除此之外，"还有一个问题是上游用于生成发布 tarball 的 CI 不可靠"。Gentoo Chromium 维护者之一曾发送补丁来修复这个问题，但收效甚微。"\[这些补丁\]花了很长时间才得到审核，之后又坏过几次。他们似乎没有注意到，也不在乎它要么没生成 tarball，要么生成的是不完整的 tarball。" Jolly 补充了他关于为 Gentoo 维护 Chromium 所遇问题的一些观察 (https://bugs.gentoo.org/982204#c53)。他说维护 Chromium 每周可能要花掉六个多小时，这还只是一台配置了"荒谬内存容量"的高速电脑上的编译时间。64 位 Arm 机器上的编译时间更长。 > 这意味着每周要投入至少一个工作日的空闲时间，包括变基补丁、挑选修复提交、在 `ebuild ... clean compile` 上反复迭代，还有试图找出并修复新的 bug，琢磨一下因为没有解绑更多浏览器组件而违反了多少 Gentoo 政策，花时间做自动化以节省日后的时间和失误，等等。保持构建跟上最新版本有着巨大的压力，尤其是在每周都有数百个浏览器 CVE 的时代。 他在关于 Chromium 最后葬礼的回复中加入了一份"预先回应的 FAQ"，说明恢复该包需要什么。他说维护 Chromium 并没有无法克服的技术难题，但需要多位拥有广泛技能的维护者——包括熟悉 C、C++、Go、JavaScript 和 Rust。"还有大量 NIH\[Not Invented Here，非我发明\]的 Google 工具需要你\[去\]学习相关技能，而且你在其他任何地方都用不上它们——言尽于此，你们被警告过了。" 使用 Google 的工具链会更简单，但那也将把 ebuild 限制在 x86-64 上。他说："我们会失去 arm64、ppc64 和 RISC-V overlay——不如现在就把创可贴撕掉，因为这并不能真正改善现状。"他补充说，如果有人愿意维护源码 ebuild，他愿意帮忙审核提交并提供建议，但他认为至少需要三个人。"历史已经表明，一个人维护是行不通的，而且自我 2023 年开始维护这个包以来，发布周期已经缩短了两次；那时候情况就不好，现在更糟了。" Chromium 的发布节奏 (https://chromiumdash.appspot.com/releases?platform=Linux) 再怎么说也算得上激进。Chromium 有多个渠道，包括 stable、beta 和 dev。大约每两周就会通过 stable 渠道发布一个新的主要分支，而且每周都会发布一个新版本。 #### 获取 Chromium 目前看来，Gentoo 用户需要到别处寻找合适的 Chromium ebuild，选择不同的浏览器，或者用其他发行方式来获取 Chromium。例如，Gentoo 用户可以从 Flathub 安装 Flatpak (https://flathub.org/en/apps/org.chromium.Chromium)，但那是一个由第三方构建的未经验证的包——并非由 Chromium 上游项目构建。此外，对于不在 x86-64 或 64 位 Arm 系统上的用户，这个 Flatpak 也帮不上忙。 Chromium 用户按上游的说明自行构建并编译这个浏览器在技术上是可行的，但看起来 Chromium 项目并不太在意让这件事变得容易。项目确实有一个关于如何获取代码的页面 (https://www.chromium.org/developers/how-tos/get-the-code/)，但指向 Linux（以及 macOS 和 Windows）说明的链接返回 503 错误。搜索说明会找到[这个页面](https://chromium.googlesource.com/chromium/src/+/main/docs/linux/build_instructions.md)，不过它已……