为什么我讨厌为 Linux 打包软件

I hate packaging my software for Linux

为了让 Fresh 软件在 Linux 上易于安装,我尝试了从 npm 到 AUR、Flatpak、AppImage 等几乎所有渠道,结果却陷入了维护泥潭。npm 存在安全隐患,Flatpak 的沙箱机制不适合终端工具,AppImage 启动缓慢,而 Debian 和 RPM 的官方入库流程又极其繁琐。更糟糕的是,GitHub 证书轮换导致 mise 失效,AUR 因安全事件被锁。面对碎片化的发行版生态,我决定放弃依赖包管理器,转而专注于构建静态链接的 musl 二进制文件,并内置自更新机制。这或许是我作为开发者能做的最务实的选择。

我唯一的愿望是让 Fresh 变得易于安装,让每个人、在任何地方都能使用——这能有多难呢?
  1. kyrofa

    哎哟,确实很痛苦。我很佩服你竟然做到了这一步,大多数维护者可不会这么做。他们通常依赖那些想用软件的人去为各自的发行版打包。不过,如果你在乎让用户用上你的软件,这里确实有点“鸡生蛋还是蛋生鸡”的问题。

    针对 Debian 的具体情况:

    > 如果有一个快速的无服务器方案就好了,你只需提供一个 URL 来查找单个软件包的新版本,apt 和 dnf 都能记住它并更新该软件包。

    你有没有考虑过直接托管自己的 Debian 仓库?这基本上就是你想要的东西。你也不需要额外的基础设施,可以直接用 aptly 或 reprepro 之类的工具托管在 GitHub Pages 上,然后从 CI 流水线把新版本丢进去。

  2. branc116

    我觉得你只需要提供你应用的 .tar 包就行了。其他一切都应该是负责不同发行版打包的人该操心的事。你不应该卷进分发流程的那一部分。如果有人想要你的应用,自然会有人去打包。软件包管理器太多了,你不可能一个个去跑,把你的东西加到所有里面去。就在静态 HTTP 服务器上放个 .tar 包,完事!

    例子:http://ftp.klid.dk/ftp/gnu/gcc/

  3. jorams

    这事儿之所以看起来这么奇怪地难,是因为你本不该做这些事。你提供源码和构建说明,然后你的工作就结束了。用户可以照着那些说明做。如果你想的话,你也可以用旧版本的 libc 编译一个二进制文件分发出去,帮助那些不想自己编译的用户。

    为发行版打包是别人的工作,他们会处理像 Debian 依赖策略之类的问题。当然,前提是人家愿意打包你的软件。

  4. _sinelaw_

    嗨,我是这篇帖子的作者(也是 Fresh 的作者)。我花了很多时间努力让 Fresh 能干净利落地分发给所有发行版的 Linux 用户,但这真是一场 uphill battle(艰难的上坡战)。我很好奇其他独立维护者是怎么应对这个问题的。提供一个能自动更新的静态二进制文件是个合理的解决方案吗?

  5. xorcist

    如果你真心想折腾自己,那你能把事情变得多复杂,简直没有尽头。

    你应该做的是把软件做得足够好,让用户愿意用,然后在自由许可证下发布源码。第一个使用并喜欢你软件的 Debian 开发者就会去打包它,然后良性循环就开始了。虽然“掌控”用户体验很诱人(毕竟每个人都想掌控自己的客户),但你必须放下这种念头。当你不掌控客户时,就别指望更新能当天推送出去,但总体而言这是件好事。

    问问发行版的人,你能做些什么让他们的更轻松,听他们的,但别试图替他们干活。除非你就住在那个发行版里,否则你不太可能理解他们期望你的软件如何表现,以及打包时的细微差别。

    Linux 打包的一个好理念就是:做软件的人和打包软件的人不是同一拨人。代码可以被审查,糟糕的想法可以被揪出来。这个原则有时会被违反,但违规发生并不代表它是个好主意。我们生活在一个没人应该毫无声誉或审查就从互联网上执行随机软件的世界里,而发行版打包提供了一种实现这一点的途径。毕竟这套方式已经存活了三十年,所以也许值得听一听。

  6. rock_artist

    我同意作者的观点。

    我开发了一个不错的跨平台专业节拍器(因为有些应用用的计时器机制不太好)。

    https://tick.talaviram.com

    Apple、Microsoft、Google——没有一个容易的,意味着你需要搞定 Play 商店、证书、代码签名、提交等等。但这些步骤虽然繁琐,结果却让那些平台获取软件变得容易。

    我也尽力想搞定 Linux,但正如作者所说,没什么简单的(我的节拍器 GitHub issues 可以证明:https://github.com/talaviram/TICK/issues)。

    难就难在名字上……Linux 有这么多分支。

    即使没有安装程序,你还要面对 X server 和 Wayland,还有 snap、AppImage、.deb,每个都不同。再加上音频插件格式(CLAP、LV2、VST3),以及有些格式根本没有指定的文件存放路径。

    对于简单应用(不是命令行工具,也不是专为包管理器设计的),我开始觉得最好的办法就是提供一个归档文件(zip/tarball 等)。

    虽然 Linux 正在增长,也是我除 macOS 之外的首选,但由于发行版太多,感觉大多数用户比其他平台的用户更懂技术。再加上 LLM 时代,你可以让它帮你安装。对于简单软件,带二进制文件的 zip 包可能是最简单的方案。

  7. s20n

    看到“Windows 和 macOS 没有 Linux 那么糟糕”这句话,我差点看花眼。

    为 Windows 打包真的非常糟糕。甚至是在 Windows 上构建应用所需的依赖项都简直是噩梦(作者提到了 winget,但这对于库来说并不好用)?

    我维护一个使用 libsfml、libfluidsynth 和一堆其他依赖项的应用。在 Windows 上打包之所以成为可能,全靠 MSYS2 和 pacman,而 pacman 本质上就是个 Linux 包管理器。

  8. snarfy

    我用 Arch,也只给 Arch 打包。我是个糟糕的维护者。如果有 Debian 的人想要,他们可以自己去为他们的发行版打包,但我看不出为什么这事儿得我来做。

同日更多故事

2026-08-12