LWN：发行版使用Flatpak

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

Distributors entering Flatpakland

By Jonathan Corbet
July 8, 2022
DeepL assisted translation
https://lwn.net/Articles/900210/

在过去的 30 年里，Linux 发行版已经发生了相当大的变化，但它们打包软件的方式却基本没变。虽然.deb 和 RPM 格式（以及其他格式）随着时间的推移有一些变化，但它们目前的形式在它们的创造者看来还是能认得出的。不过，发行商们正在推动变革。Fedora 和 openSUSE 项目都在努力减少使用古老的 RPM 格式，并在他们的大部分软件发行中改用 Flatpak；但事实证明，有些用户很难接受进行这个改变。

传统的二进制软件包里包含人们感兴趣的程序，以及它依赖的其他那些额外补充文件。该软件包还带有 metadata 元数据，描述了该程序要求还额外安装哪些软件包才能正常运行。发行版的软件包管理器使用这些依赖信息来确保每个软件包都被正确安装。

Flatpak 格式被描述为 "另一种发行格式而已"，在某种程度上，这确实是事实。一个 Flatpak 包（或者，简单地说，"flatpak"）拥有.deb 或 RPM 包之内所包含的一切内容，但也有一些明显的区别。也许最重要的一点是如何处理依赖关系。传统的软件包里会有一个（可能很长的）列表，来逐一列出所需要的每一个其他软件包；相反，Flatpak 软件包会列出一个单独的 "runtime （运行时）"，其中包含软件包构建所依据的那些基本 library 的集合。如果有一些库或其他依赖项没有出现在所选择的 runtime 中，就会直接捆绑（bundle）在应用程序的 flatpak 中。

这种安排对进行打包工作的开发者有一定的吸引力。"runtime 加 bundling "的方法简化了依赖关系的管理，这种能把系统或运行时的库文件的修改过的版本打包进来的能力被称为 Flatpak 的一个特点。针对某个特定 runtime 的软件包可以安装在任何安装了该 runtime 的系统上，这使得建立一个可以安装在多个发行版上的单一软件包就变得可行了。因此，发行商可以使用这种格式来让他们的生活更容易；专有软件包的传播者也从这个想法中看到了一些明显的吸引力。

从某种意义上说，Flatpak 已经着手解决许多与多年前命运多舛的 Linux Standard Base 的工作想解决的同样的问题。

Flatpak 设计的时候就希望能跟拥有不可改变的 core 部分的发行版能配合工作；它不会安装到/etc 或/usr/bin 等系统目录。这使得它对那些试图创建这种类型产品的发行商非常方便。

Flatpak 的另一个关键卖点是其内置的沙盒机制。用 Flatpak 安装的应用程序默认会在一个几乎不能访问底层系统或互联网的容器内运行。通过在用于构建软件包的 manifest 文件中进行声明，可以让一个特定的应用程序来申请访问权限，例如，访问用户的本地文件、互联网或 window-system server。至少在理论上，这种沙盒使安装软件包更加安全，并限制了那些被攻破的或者本身就是恶意的软件包可能造成的损害。

Flatpak 也不是没有批评者。虽然软件包可以共享同一个 runtime，但没有任何机制可以阻止 runtime 和 version 变得越来越多；这似乎已经在某种程度上变成了现实问题。运行时和软件包本身都很大，大大增加了存储空间和内存的消耗量。无论是否真有需要，应用程序经常会请求访问本地文件和互联网，以至于有些人认为 Flatpak 的沙盒声明机制是炒作多于现实。

所有这些加起来，对使用 Flatpak 形成了一些反对意见。此外，对 Flatpak 的许多反对意见似乎也可能来自于对改变事情原本做法的本能的抗拒。

Fedora's (un)filtered Flathub

在 Fedora 社区，Fedora 37 的一个修改建议已经引发激烈讨论，该建议中删除了目前应用于 Fedora 的 GNOME 软件程序中的 Flathub package repository 的那些 filter。一旦删除了 filter，Flathub 上所有可用的软件包，包括那些包含专利软件或由于专利问题等原因不能与 Fedora 一起发行的程序，都将可以被直接安装了。但 Flathub 本身作为整体来说仍将被禁用，除非用户启用了第三方软件库。

这一变动的好处是，更多的软件可以供 Fedora 用户使用，并通过沙盒化使这些软件更加安全。后者是 GNOME Software 工具在两者都可用的情况下会优先选择 flatpaks 而不是传统的 RPM 包的部分原因。但是在 Fedora 社区中，也有一些有发言权的成员强烈反对这个想法。例如，Vitaly Zaitsev 抱怨人们对 flatpaks 的偏好，说这将导致 flatpaks 在系统更新时取代 RPM 包。上面提到的很多观点，例如安装占用空间和有漏洞的沙箱，都在这次讨论中有所体现，就像对 RPM Fusion repository 的偏见一样（之前在 6 月份 LWN 已经深入讨论过）。

这些反对意见似乎不太可能阻止 Flathub 取消 filter，也不可能阻止总体上转向 Flatpak 的过渡。该发行版似乎在致力于这个方向，而 Silverblue 变体（围绕一个不可改变的 core installation 而构建），已经需要 Flatpak 了。在讨论中，Michael Catanzaro 赞扬了这种格式的安全优势，并指出，尽管抱怨了多年，Flatpak 的反对者还没有提出一个可行的替代方案来提供类似的安全优势。Richard Hughes 不太赞同 "在几乎所有情况下，用户都应该使用 Flatpaks" 的观点。除非有什么变化，否则 Fedora 的 Flatpak 的未来看起来都是确定并且会全速前进的。

OpenSUSE's ALPs are flat

早在 4 月，SUSE 宣布了一项被称为 "Adaptable Linux Platform"（ALP）的工作，在某种程度上，它是为了定义 SUSE Linux Enterprise（SLE）发行版的未来。有很多关于这个工作的文字描述，但外部观察者还是认为 ALP 到目前为止仍然相当模糊。关于 ALP 将是什么、或者它将如何影响 SUSE 的企业产品或 openSUSE，目前还没有太多公开信息。不过，已经出现的一些迹象表明，该发行版建立在一个小型的、不可改变的 core 部分之上，应用程序单独管理，很可能使用类似 Flatpak 的格式。

7 月 5 日，Dan Čermák 发布了 ALP 工作组的会议记录，该会议的重点是 "ALP Desktop 将是什么样子，以及当涉及到 ALP Desktop 时，我们如何能消除对 Flatpak 和 container 的恐惧"。会议记录指出，Flatpak 确实会被用作分发格式，但强调不需要从 Flathub 等外部来源安装 flatpaks；"打包模式不会改变，只是格式会改变"。

当被问及推动转向 flatpak 的动力以及好处是什么时，Čermák 提到了沙盒机制，但他说主要的优势在于减少了打包工作。像 Firefox 或 LibreOffice 这样的桌面应用程序可以在滚动发行的 openSUSE Tumbleweed 发行版上只要进行一次构建就能为 Tumbleweed、Leap、ALP 以及可能是 SUSE 可能创建的其他任何产品来发布了。这就不难理解为什么分销商会被一个可以大大减少维护当前复杂的应用程序 package 的工作量的方案吸引了。

在 openSUSE 社区，也有一些对使用 Flatpak 的坚决反对的意见。例如，Robert Kaiser 说："如果在发行版中用 Flatpak 那样奇怪的打包方式来替代基于 RPM 的方式，那可能是时候回到 Windows 了"。不过，作为整体来说，openSUSE 社区似乎没有对这个方向过于抗拒，至少到目前为止是这样。这可能有几个原因，包括 openSUSE 社区相对缺乏使用 Flatpak 的经验，以及 ALP 总体上的尚未定型的原因。但Čermák 的这一保证也会有所帮助：

Tumbleweed 会是需要开发工作的，但没有计划从根本上改变 Tumbleweed。你仍然可以像以前一样使用 Tumbleweed。此外，你将能够使用 "containerized 的方式"，但至少在可预见的未来，你并不是必须这样做的。

可能很快就会有这样一个时刻：在 Fedora 上开始不可避免要使用 Flatpak，至少在安装某些复杂的应用程序时需要这样。到目前为止，openSUSE 似乎并没有朝这个方向发展，所以 Tumbleweed 用户（占 openSUSE 社区的很大一部分）不必担心被不情愿地推入 Flatpak 世界。

我们不应该低估这最后一点的价值。围绕 systemd 转型出现的许多痛苦感受，肯定是由于感觉到它被强加给了那些对自己现有设置感到很满意、认为没有必要改变的用户。即使 Flatpak 像某些人所说的那样好，但如果过渡期处理得不好，也有可能造成类似的不愉快。

这种改变似乎很可能会到来；在后来的一篇文章中，Čermák 对打包一些复杂的应用程序的价值提出了质疑，并建议，如果它们被包括在发行版里的话，可能只能以 flatpak 的形式提供。Robert Schweikert 说得更简明："我们今天所拥有的东西在大约 30 年的时间里运行得相当好，但这种模式肯定已经有些显示出老态了"。进行开发来满足当前的需求正是发行版提供商所需要做的，而这种发展肯定会带来最终用户可见的变化。关键是在处理这些变化时要同情这些用户，希望能避免我们在过去的改动中看到的一些动荡。

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

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

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