LWN:Fedora同意提供预编译的macOS二进制文件!
共 3384字,需浏览 7分钟
·
2024-06-12 13:21
关注了就能看到更多这么棒的文章哦~
Fedora approves shipping pre-built macOS binaries
By Joe Brockmeier
May 29, 2024
Gemini-1.5-flash translation
https://lwn.net/Articles/975445/
Asahi Linux 项目致力于在 Apple Silicon 硬件上支持 Linux。该项目的 旗舰 发行版是 Fedora Asahi Remix,它拥有自己的 安装程序(而不是 Anaconda)来满足在 Apple 硬件上安装的独特需求。之前安装程序是由 Asahi 项目构建的,但它已向 Fedora 工程指导委员会 (FESCo) 申请(并获得了)豁免,以包含来自上游开源项目的两个二进制文件,以便安装程序可以在 Fedora 基础设施上构建。
pple Silicon 不支持像将 USB 驱动器插入并重新启动到 Linux 安装程序那样简单的事情。想要在 M1 或更高版本的 Mac 上安装 Linux 的用户必须在 macOS 中启动安装,调整磁盘大小以便为 Asahi 留出空间,然后重新启动到 macOS 恢复(recoveryOS)以完成安装。Asahi Linux 通常与 macOS 一起安装,因此用户可以选择启动到任一操作系统,尽管用户可以完全删除 macOS 分区。作为该过程的一部分,Asahi 将用于系统恢复的 macOS 内核替换为 Asahi 的 m1n1 引导加载程序,用于 Apple 硬件。Apple Silicon 的整个启动过程在 Asahi 的 2021 年 1 月/2 月进度报告 中有很好的描述。
这意味着安装程序(用 Python 编写)需要两个 macOS 二进制文件才能执行安装:用于 macOS 的 Python 解释器和 libffi,后者由 Python 在 recoveryOS 中使用,用于从 macOS 内核中提取固件供 Linux 使用。不幸的是,它需要 Xcode 在 macOS 上构建这些文件,因此无法在 Linux 上构建二进制文件,这意味着需要分发预构建的二进制文件。
根据 Fedora 的 打包指南,所有“程序二进制文件和程序库”都应该从源代码构建,以确保安全并确保它们使用标准的 Fedora 编译器标志。(这并不扩展到 content 二进制文件,如图像或 PDF 文件,这些文件可以包含在内,无需相应的源代码。)由于这是不可能的,Asahi 贡献者 Davide Cavalca 于 5 月 15 日 请求了豁免,用于 macOS 上的 Python 构建和来自 Homebrew 项目的 libffi 构建:
我们特别想这样做,因为它将使我们能够向用户分发一个也在 Fedora 中构建的 m1n1 阶段 1(Asahi Linux 安装程序会自带一个预构建的)。
Neal Gompa 回复道“这可能没问题,因为从我们的角度来看,macOS 是‘固件’”。Tom Stellard 想知道是否可以交叉编译二进制文件,而不是引入在 macOS 上生成的二进制文件。Cavalca 回答说他不相信这样做在实际操作上是可行的,除非在 Linux 之上运行带有 Xcode 的 macOS 虚拟机。在某个时刻,可以使用 Darling,这是一个旨在在 Linux 上运行 macOS 软件的项目,“但我认为它目前还不能使用(这也是我们目前还没有打包它的原因)。”
前 FESCo 成员 Miro Hrončok 表示,他可能会反对允许这种例外情况。他争辩说,允许为 macOS 预构建二进制文件将打开大门,允许完全放弃从源代码构建所有内容的要求。他还问“我们如何知道 macOS 二进制文件不包含一些专有的 macOS/Xcode 代码?”并 建议将该请求在邮件列表或 Fedora 的 Discourse 论坛上进行讨论,但讨论从未继续进行。
Cavalca 说他还没有审核过这些二进制文件,但它们来自官方的上游来源(分别是 Python 和 Homebrew)并且是可重新分发的。他以一种迂回的方式回答了 Hrončok 关于专有代码的问题,他说使用 Xcode 并不排除重新分发,“否则你将无法将编译器用于许多事情”。
此事在 FESCo 的 5 月 20 日会议 上被列为新业务。(不幸的是,Fedora 会议的会议日志格式不允许直接链接到单个评论或时间戳。讨论从 19:11:58 开始。)在会议期间,有人指出,Fedora 项目还有另一个程序是在 Fedora 的 Koji 构建系统之外构建的,该程序针对 macOS:Fedora 媒体写入器。Josh Stone 问了如何处理这个问题,Stephen Gallagher 回复说“处理得不好”。Gompa 接着解释说,macOS 二进制文件是在其他地方构建的,然后提交给 Fedora 发布工程进行 公证(由 Apple 数字签名),以便 macOS 用户 不会收到警告在运行程序时。
经过一番关于 macOS 工具链的奇特之处和问题许可的讨论后,Gallagher 说他不明白如果 Fedora 不控制构建系统,打包二进制文件的优势。Cavalca 说,让安装程序包由 Fedora 构建意味着“我们将从安装程序是一个随机的不可信 blob 变为一个可信的包,它依赖于两个更小的 blob”。
最终,Zbigniew Jędrzejewski-Szmek 说他最初反对该提议,但后来转而“更积极地看待”。他指出,该代码不会在 Fedora 上运行,而是在 macOS 上运行,并且接受上游二进制文件是最好的解决方案:
我们不是构建 macOS 东西的专家,因此复制已经完成的构建不会给我们带来太大帮助。它很可能会引入更多问题和错误。并且由于该代码永远不会在 Linux 系统上执行,因此它就像固件一样,即我们出于实用原因而接受的东西。
在讨论该主题约 50 分钟后,Gallagher 要求进行投票。(会议日志中的时间戳为 19:50:20。)David Cantrell、Kevin Fenzi、Josh Stone 和 Stellard 都投票反对该例外情况。Major Hayden、Tomáš Hrčka、Gallagher、Gompa 和 Jędrzejewski-Szmek 投票支持,以五票对四票的优势批准了该例外情况。投票结束后,Gallagher 说:“这是我一段时间以来看到的最有争议的投票”。
在会议记录发布到 Fedora 开发邮件列表后,Hrončok 写道:“我有点难过,FESCo 在没有事先与更广泛的社区讨论的情况下就批准了这件事。”Fenzi 同意。
对于 Asahi Linux 用户来说,几乎不会有任何变化。安装程序将继续与以前一样工作,但它将使用 Fedora 基础设施构建。看看这是否为预构建的二进制文件设定了先例,或者最终成为帮助用户从专有操作系统迁移的唯一一次让步,将会很有趣。我们很快就有机会找出答案:FESCo 也被要求批准 一项例外情况,以允许签署的 SGX enclave 二进制文件用于运行机密虚拟机,并且应该很快就会处理这件事。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注,关注 LWN 深度文章以及开源社区的各种新近言论~