我讨厌为 Linux 打包我的软件

原文 ↗ Hacker News 讨论 ↗

独立开发者正努力在一个碎片化的生态中分发 Linux 应用，这里有不同的发行版、包管理器和运行时假设。许多人认为，让单个维护者支持所有格式并不现实，因此主张要么发布简单的静态二进制文件，要么把打包工作留给发行版维护者，即便这会限制覆盖面和自动更新的便利性。也有人探索自更新二进制、容器式方案（Flatpak、Docker、Nix）或外部工具等变通办法，但对于通用、低摩擦的解决方案并没有共识。

问题范围

  • 讨论串认为 Linux 打包是碎片化的：有很多发行版、很多包管理器，再加上更新的一些层（Flatpak、Snap、AppImage、Nix、Homebrew 等）。
  • 独立维护者发现要覆盖所有发行版并持续更新很困难，尤其是对于依赖不简单的项目（例如包含很多 crate 的 Rust、Python 等）。

应该由谁来打包？

  • 一派观点：开发者主要应发布源码、简单的构建说明，或许再提供一个 tarball 或静态二进制文件；具体发行版的打包应由发行版维护者负责。
  • 反方观点：依赖发行版意味着如果没人站出来维护，软件实际上就会无法获得；用户也可能没有技能或时间去打包或构建。
  • 有人认为这“几十年来一直都行”；也有人指出这会过滤掉软件，并让非专家用户感到沮丧。

静态二进制与自更新二进制

  • 许多人认为，单个静态（或大部分静态）的二进制文件加上内置自更新，是最务实的跨发行版方案，尤其适合 CLI/TUI。
  • 被提到的例子包括：其他 Rust 工具、Firefox 自己的更新器，以及各种 Go/Rust 实用工具。
  • 顾虑包括：性能（musl 与 glibc）、自修改可执行文件的安全性，以及来自部分 Linux 圈子的社会性反对。

替代分发渠道

  • 类容器方案：Docker/Podman/systemd-nspawn，或直接分发完整用户态/squashfs，被认为可靠但很重，尤其对嵌入式或低存储系统来说。
  • Steam/Proton：有人建议用它来为 GUI 应用获得长期、稳定的运行时，但对非游戏来说体验有些奇怪，而且依赖一个专有平台。
  • Flatpak：对 GUI 应用效果很好，但 CLI/TUI 支持和权限模型被认为有些别扭。
  • 还提到了 Nix、OBS、PPA、个人 Debian 仓库、Linux 上的 Homebrew 等，它们都很有用，但各自也带来复杂性和学习成本。

从源码构建与工具链

  • 传统的 ./configure && make && make install（或 cargo install）在一些人看来仍然可行；另一些人则说由于依赖不匹配，它经常失败。
  • 一些评论建议使用现代工具和 CI（Nix、GitHub Actions、Open Build Service、checkinstall），甚至使用 LLM 自动生成打包元数据。

与 Windows/macOS 的比较

  • 多位发言者声称，Windows 打包在实践中更容易：把所有 DLL 和应用一起捆绑，然后发布安装程序即可。
  • macOS 和移动平台有各自的官僚流程（证书、商店），但至少提供了一条相对统一的路径，不像 Linux 生态那样分散。