Gentoo Chromium 包的最后安魂曲

# Gentoo 的 Chromium 软件包的最终告别 来源：https://lwn.net/Articles/1097760/ > **请考虑订阅 LWN** > 订阅是 LWN.net 的生命线。如果您欣赏这些内容并希望看到更多，您的订阅将帮助确保 LWN 持续繁荣发展。请访问[此页面](https://lwn.net/Promo/nst-nag1/subscribe)加入订阅，让 LWN 继续留在互联网上。 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 用户来说是可选的，但对于其他架构上的用户来说 `-bundled-toolchain` 是必需的，因为 Chromium 的捆绑工具链仅随 x86-64 提供。 值得注意的是，由于在构建包含专有编解码器的软件包时存在问题，Chromium 目前不作为二进制包由 Gentoo 提供。 #### 最终告别 许多发行版，包括 Arch Linux、Debian 和 Fedora，使用"孤儿"（orphan）一词来指代已被维护者遗弃的软件包；开发者宣布某个软件包成为孤儿后，其他贡献者有机会认领其维护权。Gentoo 的术语更加戏剧化：软件包维护者在 gentoo-dev-announce 邮件列表上宣布某个软件包的"最终告别"（last rites），以通知项目它将不再被维护，并作为让其他开发者认领维护权的机会。 在开发者宣布最终告别之后，该软件包的 ebuild 会在 Gentoo 的 ebuild 仓库（https://wiki.gentoo.org/wiki/Ebuild_repository#The_Gentoo_ebuild_repository）中被屏蔽（https://wiki.gentoo.org/wiki/Knowledge_Base:Masking_a_package），以确保用户不会意外安装不再被维护的软件包。已经安装了该软件包并尝试升级的用户会收到它已被屏蔽的警告。Chromium 软件包维护者 Sam James 于 9 月 24 日在 Roman Žilka（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 个已知漏洞，涵盖所有严重级别。需要有合格的人来采取措施，防止这种事在如此重要的软件包中反复发生。 他在错误报告中附上了一个更新版本 Chromium 的 ebuild（https://982204.bugs.gentoo.org/attachment.cgi?id=970220），但指出如果用户尝试使用 `-bundled-toolchain` USE 标志编译 Chromium，它将无法工作。 James 回复（https://bugs.gentoo.org/982204#c5）说："Chromium 作为源代码软件包简直惨不忍睹。它显然是 Gentoo 中最消耗维护者的软件包。" 他说抱怨维护工作毫无帮助，并补充说多年来维护者们曾多次接近为 Chromium 宣布最终告别，因为更新到最新版本太困难了。他还提到他之前已经向 Žilka 提到过这一点，并表示如果他愿意协助该软件包，将受到欢迎。 事实上，Žilka 在 8 月也曾提交过类似的错误报告（https://bugs.gentoo.org/980389），抱怨 Chromium ebuild 中存在大量漏洞；James 当时回复（https://bugs.gentoo.org/980389#c1）说该软件包一直很难维护，"现在他们又加入了 Go 作为依赖"。在此之前，Žilka 就曾在 Matt Jolly 提交的关于 Chromium 漏洞的错误报告（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 自愿提供帮助。 #### 试错 有各种第三方仓库，称为 overlays（https://wiki.gentoo.org/wiki/Project:Overlays），为 Gentoo 提供额外和替代的 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 软件包的问题。他说在错误报告中提交的补丁和 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 的 diff 来逆向工程这些变更，并弄清楚哪些地方被修改了。"所有这些都是不小的工作量，虽然有一些 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 中一直有让维护者精疲力竭的历史，不过这个错误报告中的一些内容也丝毫不助于激励。" 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，要么生成的是不完整的。" Jolly 补充了他关于在 Gentoo 上维护 Chromium 的一些观察（https://bugs.gentoo.org/982204#c53）。他说维护 Chromium 每周可能需要超过六个小时，而且这还只是在一台具有"大量内存"的高速电脑上的编译时间。64 位 Arm 机器的编译时间还要更长。 > 这意味着每周要至少投入一个工作日的业余时间，包括 rebase 补丁、cherry-pick 修复、反复执行 \`ebuild ... clean compile\`，以及尝试识别和修复任何新错误、弄清楚不在更多地方解捆绑浏览器会在多大程度上违反 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 有多个渠道，包括稳定版、测试版和开发版。大约每两周通过稳定渠道发布一个新的主要分支，每周发布一个新版本。 #### 获取 Chromium 目前，Gentoo 用户似乎需要在其他地方寻找合适的 Chromium ebuild，选择其他浏览器，或者找到其他分发方式来获取 Chromium。例如，Gentoo 用户可以安装来自 Flathub 的 [Flatpak](https://flathub.org/en/apps/org.chromium.Chromium)，但它是由第三方构建的未验证软件包——不是由 Chromium 上游项目构建的。Flatpak 对于不在 x86-64 或 64 位 Arm 系统上的用户也没有帮助。 从技术上讲，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)，不过它没有日期，所以不清楚它是否是最新的。