关于 Arch Linux .pacman 构建产物与 Linux 二进制分发方式的建议

[nlsdt]

我是 AUR 源码包、archlinuxcn 仓库包 splayer-next 的维护者，同时也是 archlinuxcn 仓库的成员。在使用上游 CI 产出的 .pacman 包进行打包时，遇到了一些问题，想在这里和上游讨论一下 Linux 分发格式的选择。

当前 .pacman 构建产物的问题

electron-builder 的 pacman target 目前存在以下限制：

格式不规范。 electron-builder 官方文档(https://www.electron.build/docs/linux/#pacman-package-pacman)将 pacman target 标注为 beta，并建议“分发前彻底测试”。产出的文件后缀 .pacman 并非 Arch 标准包格式（标准为 .pkg.tar.zst，见 https://wiki.archlinuxcn.org/title/Pacman#Installing_packages ），pacman 本身不正式认可该后缀。

依赖元数据不可靠。 electron-builder 生成的依赖声明可能包含已从 Arch 仓库移除的包名，或仅存在于 AUR 的包名，导致用户执行 pacman -U 时直接报错，安装无法完成。Arch 的 pkgver 不允许连字符，electron-builder 在处理预发布版本时可能产出 Arch 不接受的版本号。

系统集成不完整。 上游 .pacman 包内没有 /usr/bin 入口，.desktop 文件路径与图标关联未经桌面环境验证，chrome-sandbox 的 SUID 权限在包中不一定被正确设置。

当前能行的实际做法

由于上游只提供 .pacman，下游打包者目前的做法是：将 .pacman 当作 rootfs 归档，用 bsdtar 解包，跳过 pacman 依赖解析，手动补全 /usr/bin 入口、.desktop 文件、图标和沙盒权限，再重新打包为 Arch 标准包。

这种做法并不稳定，不太建议这么干

建议

第一，从文档中移除 .pacman 作为 Arch 用户推荐安装方式。

Arch 用户已有更可靠的路径：AUR 源码包 splayer-next 走源码构建，依赖和集成由打包者按 Arch 规范处理；archlinuxcn 仓库提供预构建二进制，通过 lilac 自动构建，用户启用源后可直接安装，安全更新由仓库统一推送。这两条路径都能保证正确的入口、桌面集成和沙盒权限。

如果保留 pacman 格式用于 CI 内部测试或特定场景，建议在文档中标注“实验性，不建议 Arch 用户直接使用”，并将 Arch 用户引导至 AUR 或 archlinuxcn。

第二，增加一个真正的二进制 tarball 作为下游打包输入。

electron-builder 本身支持 tar.gz target。建议在 CI 中额外产出 tar.gz，包含完整的 linux-unpacked 目录：Electron 运行时、app.asar、原生模块、chrome-sandbox 等。

下游打包者可以直接解压，按各自发行版规范重新打包，不需要再逆向处理 .pacman 的内部结构。
这样后面如果有 nix 等其他发行版也想进行下游打包，也会更方便一些。

总结

建议的目标状态是：.pacman 不再作为 Arch 用户推荐路径，新增 tar.gz 作为下游打包的标准输入，Arch 用户统一引导至 AUR 或 archlinuxcn。

以上建议供讨论。感谢各位开发者和贡献者的辛勤工作！

---

cc @K-Blaaaack