Flatpak 将依赖 systemd
摘要
Flatpak 的下一个重要版本可能将依赖 systemd,以将权限管理移至服务层,这可能会破坏与不使用 systemd 的发行版的兼容性。
<p><a href="https://lobste.rs/s/gfbpgq/flatpak_will_depend_on_systemd">评论</a></p>
查看缓存全文
缓存时间: 2026/05/24 23:01
# Flatpak 将依赖 systemd —— OSnews
来源:https://www.osnews.com/story/145071/flatpak-will-depend-on-systemd/
首页(https://www.osnews.com/)> Linux(https://www.osnews.com/topic/linux/)> Flatpak 将依赖 systemd
如果你今天访问 Flatpak 官网,它会将以下内容列为项目的首要优势:
*“为每个发行版构建:创建一个应用,然后分发到整个 Linux 桌面市场。”*
如果继续查看支持的分发版列表,你会发现常见的发行版,也包括 Void Linux、Guix 和 Alpine。最后这三个发行版有一个共同点:它们使用的初始化系统都不是 systemd,因为 Flatpak 并不关心你使用什么初始化系统。然而,对于下一个主要版本的 Flatpak,这种情况似乎即将改变:systemd 很可能会成为 Flatpak 的一个依赖项。
在 Linux 应用峰会上,Arian Vovk 和 Sebastian Wick 进行了一场精彩的演讲(https://www.youtube.com/watch?app=desktop&v=1AXBfsiaQNk&t=16218s),内容关于 Flatpak 的未来。当前版本的 Flatpak 将继续迎来大量改进,但同时,基于几十年前设计的方案所能做到的极限已经越来越难以绕过。因此,他们也在规划和开发所谓的 Flatpak Next(或者 Flatpak 2.0)。这实际上是对 Flatpak 的重写,基于多年积累的经验,并利用自 Flatpak 1.x 最初设计以来获得普及的现代技术和理念。
需要强调的是,演讲中讨论的所有内容都处于规划阶段,尚未编写一行代码。这意味着所有这些计划都可能发生变动,并且随着未来几年的工作推进,最终结果可能与演讲中详述的内容大相径庭。此外,我再三强调:如果本文的任何内容让你哪怕有一丝冲动去骚扰、攻击、侮辱或以其他方式打扰任何参与 Flatpak、systemd 或相关技术的人,请务必预约一节瑜伽课或类似活动——你似乎很需要它。
在演讲的开头,Vovk 和 Wick 解释了他们希望将权限管理从 Flatpak 迁移到服务层,通过一个名为 systemd-appd 的新服务来实现。Systemd-appd 为应用程序分配标识符并存储其权限,然后系统的其余部分可以查询这些数据。这反过来又启用了一系列其他功能,尤其是子沙箱功能。目前,计划是将此功能引入当前版本的 Flatpak,从而将 systemd 的依赖引入 Flatpak。
根据我从 Vovk 了解到的信息(https://fosstodon.org/@AdrianVovk/116629630385486477),他们原本打算“超级体贴”地考虑那些不使用 systemd 的发行版和用户。我的理解是,最终可能会形成类似 systemd-logind 的局面。Systemd-logind 已从 systemd 中提取为一个独立的守护进程 elogind(https://github.com/elogind/elogind),以便使用其他初始化系统的发行版仍能利用依赖于 systemd-logind 的桌面环境。我推测 Flatpak 开发者曾希望尽可能为 systemd-appd 实现类似的情况,从而确保 Flatpak 在不使用 systemd 的发行版上仍能可用。
显然,使用 Void 或 Alpine 等发行版的用户对 Flatpak 在其系统上的未来感到担忧。如果 Flatpak 对 systemd 产生硬依赖,那么在没有 systemd 的发行版上,Flatpak 将无法运行。因此,演讲引发了疑问——可惜的是,这些问题似乎被指向了一个(https://hachyderm.io/@jorge/116607961190448307)在技术上并未参与 Flatpak 开发的人,而他的回复(https://hachyderm.io/@jorge/116625332558398598)并不特别有帮助,甚至常常是彻头彻尾的侮辱(https://hachyderm.io/@jorge/116619028047490652)和煽动性言论(https://hachyderm.io/@jorge/116625264102622684)。
尽管他并未参与 Flatpak 开发,但足够多的人以为他是,于是一场有毒的纷争被点燃了。带着真诚、友好问题询问 Flatpak 在其系统上未来的用户,遭到了嘲笑和侮辱,事态从此失控,并吸引了那些狂热的反 systemd Red Hat 阴谋论疯子(甚至更糟)。对于所有相关方来说,情况变得越来越糟,尤其是对于 Flatpak 的开发者。
最终我们落到了这样的局面:每个人都愤怒不已,而 Flatpak 的开发者“不再有心情(https://fosstodon.org/@AdrianVovk/116629630385486477)在这些破事上花时间”来照顾和让步于那些不使用 systemd 的发行版和用户。最终结果很可能是,未来 Flatpak 对 systemd 的依赖将更为严格,而制作任何类似 elogind 的独立守护进程将比原本更加困难。没有人赢,每个人都输了,仅仅是因为有些人认为侮辱和煽动是必要且富有成效的。
就目前情况来看,在未来几年内,Flatpak 很可能会增加对 systemd 的依赖,而且很可能没有为独立守护进程提供任何变通方案,以便在不使用 systemd 的发行版上复制 systemd-appd 的功能。换句话说,Flatpak 将不再能够宣称它支持“为每个发行版构建:创建一个应用,然后分发到整个 Linux 桌面市场”,因为它将不再与发行版无关。这很可惜,因为无论用户使用何种初始化系统,Flatpak 都满足了他们的真实需求。
而这显然正是某些人将其全部身份建基于此的原因——因为他们是怪人。
#### 关于作者
##### Thom Holwerda(https://www.osnews.com/story/author/thom-holwerda/)
在 Mastodon 上关注我 [@\[email protected\]](https://exquisite.social/@thomholwerda)
相似文章
包管理器中的补丁与分支策略
本文探讨了在上游维护者未能解决漏洞时,针对不同语言包管理器修补和分支依赖项的策略。文章对比了系统包管理器强大的修补能力与语言注册表的局限性,并详细介绍了在各种生态系统中使用 Git 覆盖和分支等变通方法。
Arch Linux: 对所有使用 `varnish` 用户的重大变更,该软件包已更名为 `vinyl-cache`
Arch Linux 通知用户,varnish 软件包已更名为 vinyl-cache,需要手动迁移配置文件、目录、用户和 systemd 单元。
改进我的自托管 Actions Runner 设置
作者通过用 systemd-nspawn 容器替换 Docker 来改进其自托管的 Gitea Actions Runner 设置,以提高安全性,并详细说明了配置和权衡。
你对 systemd 定时器的爱还不够
本文提倡在 Linux 上使用 systemd 定时器替代传统的 cron 作业来执行定时任务,强调其更好的集成性、日志记录以及更清晰的语法。
为KDE Plasma最后一个支持X11的版本做准备
KDE宣布Plasma 6.8将放弃X11会话支持,在经历15年开发后完全过渡到Wayland。这一变化仅影响Plasma桌面本身;XWayland支持仍保留用于传统应用程序。