LWN：在Fedora中打包Rust应用！

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

Packaging Rust for Fedora

By Jonathan Corbet
October 28, 2022
DeepL assisted translation
https://lwn.net/Articles/912202/

Linux 发行版设计的时候，当时的通用原则是用 C 语言来写程序，因此人们所关心的大多数软件都是用 C 语言编写的。发行版也就自然而然地可以高效打包发布 C 语言应用程序以及它们所依赖的库了。然而，现代语言往往是围绕着他们自己的打包管理系统（package-management systems）来设计的，这些系统的设计目标各有差异。于是多年来，发行版提供方一直在针对用这些语言编写的应用程序来寻找最佳打包和发布方式。最近在 Fedora 社区进行的关于 Rust 应用程序打包方式的讨论表明，这些问题还没有全部解决。

引起这次讨论的是 Panu Matilainen 提出的一个针对 Fedora 38 的修改建议。RPM 软件包管理器长期以来一直使用自己内部 OpenPGP 解析工具（parser）来管理软件包的密钥和签名。这个解析工具似乎没有人喜欢；在这个提案中它被描述为 "因其局限性和缺陷而臭名昭著"，并提出了一个计划来用 Sequoia 库取代它，该库是用 Rust 编写的（2020 年曾在 LWN 介绍过）。使用 Rust 可以提供一些 safety 保证，因此在这种跟安全相关的代码中是很受欢迎的，但对于担心 Rust 如何融入整个发行版的开发者来说，它也可能是一个显眼的标志。

不可避免地，有人对这个提议提出了抱怨。例如，Kevin Kofler 就问为什么不选择用 C 语言编写的库。据 Matilainen 说，已经花了很多年来寻找这样的库，但是一直没有成功。最明显的替代方案，GPGME，是不能满足要求的，因为它是围绕着与外部 GPG 进程的通信而建立的，"这种配置，你肯定不希望在 rpm 环境下（比如频繁进行 chroot 等）看到"。Neal Gompa 同意 GPGME 工作模式在这种环境下会很难用，并且似乎同意没有比 Sequoia 更好的选择，尽管他自己跟 Rust 社区有不少分歧："所以我们现在就是这么个情况，处于一个由糟糕的工具造成的不舒服的情况，因为反正没有多少人非常关心 security"。

Kofler 继续概述了他认为 Rust 语言存在的问题。其中一个是，它是又一种需要处理的语言，这个抱怨在名单上并没有引起很多人的共情。不过，他的另一个反对意见则让大家更加感同身受：

我认为 Rust 最糟糕的问题是库文件的 "打包" 方式，这意味着要为每个应用程序安装源代码并重新编译。(结果是，输出文件显然要被静态链接到应用程序中，也就具有了静态链接所有的缺点）。我认为一种没有可以使用的共享库（shared library）支持的语言是完全不可以打包发布的，因此完全没有价值。

Fabio Valentini 负责为 Fedora 打包 Rust crates，他指出 Sequoia 实现为一个具有 C ABI 的共享库，因此不需要将什么 Rust 代码静态链接到 RPM 中。他询问 Kofler 是否有任何建设性的建议来改善这种情况。Kofler 的答复中没有给出正面回应。不过，Fedora 项目负责人 Matthew Miller 确实有一些想法。

具体来说，他同意 Kofler 的观点，即 Rust 应用程序最终可能完全是 "不可打包发布的"。他提到了他在 Bevy 游戏引擎方面所做的工作；他发现调用 Cargo 构建系统来获取 Bevy 的构建依赖项会获取超过 390 个独立的 crate，其中大约一半是目前没有在 Fedora 中打包发布的。试图对这样一个应用程序打包发布，肯定是很痛苦的，但是，他说，"开源胜利之后的世界就是这样的"。Cargo 使软件组件的共享和重用变得容易，这是一个很大的好处，但它使所有这些依赖关系的独立打包发布变得更加困难。事实上，这些依赖关系中有许多是依赖相关 crack 的特定版本的，这使得这个任务更加困难。

所有这些，都使他质疑为 Fedora 打包 Rust crate 的工作的价值。他也有与众不同的想法，认为 Rust 可能是一个探索使用新的方法的机会。他说："有些东西是轻量级的，我们可以在构建应用程序 RPM 的过程中 直接 使用它们"。他的意思很明显，就是不试图打包所有的依赖关系，也不发布动态链接的可执行文件，这样 Fedora 可以更直接地跟 Cargo 生态系统配合起来，节省大量（在他看来）没有多少价值的工作，并且更容易将应用程序推广给用户。他总结说，Fedora 需要适应当前的开发环境，从而让自己保持不被抛弃。

应该不会有多少读者对 Valentini 反对这个观点感到惊讶。他说，Bevy 是一个有点特殊的情况；大多数 Rust 应用程序相对比较容易在 Fedora 中打包发布，因为最流行的那些 crack 已经打包好了。他补充说，Cargo 和 RPM 的工作方式很类似，这使得打包工作更容易；在许多情况下，RPM spec 文件可以直接根据 Cargo metadata 来自动生成。同时，打包工作带来了人们已经习惯了的所有优势，包括跨架构的测试、代码和 license review，以及将贡献推送到 upstream 从而使未来的打包工作更容易。

他说，试图改变 Rust 应用程序的打包过程，反而会使事情变得更糟。他说，这就是 Node.js 和 Java 面临的问题（6月时 LWN 曾报道过一些 Java 的讨论）。他总结说，总的来说，Rust 的情况相对较好，如果试图做一些不使用 "纯粹 RPM 包" 的事情，可能会造成更多的问题，而不是解决问题。

ofler 则不赞同这个 Rust 可以更加容易地添加依赖关系的观点，称这里得到的是 "dependency hell（依赖地狱）"。他说，与其说是 Fedora 适应了 Rust，不如说是 Rust 为了避免被抛弃而应该要努力适配 Linux 发行版。不过 Gompa 不太认为事情会按这个方向走，他说他在这个方向的努力在过去遇到了很大的阻力。

谈话到此结束，没有任何明确的结论。有一个相关的问题没有得到解决，但值得考虑，并且在 RPM 中使用 Sequoia 的时候也得到了强调。只要开发者坚持使用相关的语言，跟特定语言相关的环境就能很好地工作；当面临需要将多种语言编写的代码结合在一起时，它们就很难坚持住了。目前使用的发布方式，试图使所有软件包都能很好地配合起来共同工作，展示出了它的价值。鉴于 Rewrite The World In Rust 项目注定要花几年时间才能得出最终结论，看来在一段时间内，这些混合了多种语言的应用程序的数量可能会增加，而发行版提供商则需要能够打包和发布这些应用程序。

就目前而言，为 Fedora 打包 Rust crate 的做法可能会继续下去，不会有重大变化。但发行版以及特定语言软件包管理器之间的配合的话题，估计也必定会在未来经常出现。不是很容易能找到一种方法让这些独立的生态系统可以顺利地互动，但如果可以的话，对所有参与者都有好处。这是一个值得努力解决的问题。

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

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

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