Shelly-ALPM：用 GTK4 和 Zig 重写 Arch 包管理体验，但值得换掉 pacman 吗
ArchLinux 的 Pacman 替代品，专为您而设计。 Native Wayland 支持：使用 GTK4 构建的前端。
秒懂
- 它是什么？
- Shelly 是一个直接调用 libalpm 的 Arch Linux 包管理器，提供 GTK4 图形界面和配套 CLI。它解决了 pacman 没有原生图形前端的问题，但引入了一个仍在快速迭代的额外抽象层。
- 适合谁用？
- Shelly 适合两类人：一是想要图形化包管理界面的 Arch 新手，二是愿意接受新工具链的终端用户。不适合追求最小依赖或对 pacman 已有深度脚本依赖的人，因为 Shelly 的 CLI 输出和配置格式与 pacman 不兼容。
- 能商用吗？
- 可以，但有条件。GPL-3.0 是 copyleft 许可证：如果你分发包含它的软件，就必须以同一许可证公开该软件的源代码。只在内部运行、不对外分发，则不会触发这项义务。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Zig（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
pacman 没有图形界面，Shelly 想补上这个缺口
Arch Linux 的官方包管理器 pacman 只有命令行。对新手来说，安装软件需要记住 pacman -S、pacman -Rns 这些参数，出错时面对的是原始错误输出。Shelly 的目标是提供一个更友好的入口，同时不放弃底层能力。它直接调用 libalpm，而不是像一些工具那样解析 pacman 的文本输出。这意味着它理论上能获得与 pacman 一致的事务语义。项目描述里强调这是「complete reimagination」，不是给 pacman 套一层皮。但重新想象也意味着重新实现，而 libalpm 的 API 并不简单。Shelly 用 Zig 写核心逻辑，GTK4 做界面，这种技术选型在包管理器领域很少见，也决定了它的开发节奏和生态位。
从 GTK4 界面到 CLI，Shelly 拆成了五个组件
仓库结构把功能拆成独立模块。Shelly.Ui.Gtk 是桌面应用，Shelly.Cli.Zig 是命令行工具，Shelly.PackageManager 承载 libalpm 和 AUR 的核心逻辑，Shelly.Http 是一个带兼容 TLS 实现的 HTTP 客户端，Shelly.Flatpak.Backend 是可选的共享库。这种拆分有一个实际好处：Flatpak 支持不是默认依赖。README 明确说，基础安装只包含 ALPM、AUR、AppImage、帮助和版本命令，Flatpak 后端只在执行 Flatpak 操作时加载。这避免了强制安装 flatpak 和 GLib 依赖。但代价是架构复杂度。每个模块都有自己的 zig build 测试，还专门写了一个 scripts/test-flatpak-separation.sh 来验证 ELF 边界。对一个包管理器来说，这种模块化是合理的设计，但也意味着用户升级时需要关注组件之间的版本匹配。
安装方式：CachyOS 仓库最快，AUR 和 PKGBUILD 是备选
推荐的安装命令是 sudo pacman -S shelly，但这只对 CachyOS 或配置了 CachyOS 仓库的系统有效。普通 Arch 用户需要走 AUR：yay -S shelly 或 paru -S shelly。项目也提供了 git PKGBUILD，你可以克隆仓库后复制 PKGBUILD-git 为 PKGBUILD，然后运行 makepkg -si。手动构建需要 zig 0.16.0 和 vala，这两个版本要求比较具体，如果你的系统 pacman 仓库里的 zig 版本不同，可能需要手动安装。卸载同样区分标准包和 AUR 包，前者用 sudo pacman -Rns shelly，后者用 yay -Rns shelly。这里有个值得注意的细节：README 没有提 pacman -Qi 能查到的文件清单，所以卸载后如果想确认没有残留配置文件，需要自己检查 ~/.config/shelly 目录。
CLI 不只是简化版 pacman，它有自己的配置体系
Shelly 的 CLI 命令叫 shelly，与 pacman 的语法不同。README 给出的例子是 shelly build --makesrcinfo --reviewed PKGBUILD，这个命令从已审查的 PKGBUILD 生成 .SRCINFO，而不运行构建生命周期。这比手动写 .SRCINFO 要安全，因为格式由程序生成。CLI 使用 JSON 配置文件，首次运行自动创建 ~/.config/shelly/config.json。JSON 配置比 pacman 的 /etc/pacman.conf 更现代，但也是迁移成本。如果你有脚本依赖 pacman 的文本输出，Shelly 的输出格式大概率不一样。文档里没有列出所有配置键，只提到完整列表在官方配置页面。这意味着实际使用前你得先跑一次 shelly，看看生成的默认 JSON 里有哪些字段，再决定怎么改。
Flatpak 支持是可选的，但 ABI 约束很严格
Shelly 的 Flatpak 集成不是简单的调用 flatpak 命令。它专门有一个 Shelly.Flatpak.Backend 共享库，封装了 libflatpak 和 GLib 的实现细节。README 提到这个后端的 ABI、内存所有权、发现规则和版本升级流程都记录在 docs/flatpak-backend-abi.md 里。这透露出一个信号：这个后端不是随手加的，它有严格的接口约定。测试命令包括 abi-test、parity-test 和 integration-test，说明团队在维护二进制兼容性。但这也意味着，如果你不使用 Flatpak，这个库的复杂度对你毫无价值。反过来，如果你依赖 Flatpak 应用，Shelly 的集成方式可能比手动用 flatpak 命令更方便，但你得信任这个后端的稳定性和安全性。毕竟它涉及加载共享库，而包管理器本身就有高权限。
路线图里的功能还没落地，别指望它现在就有
README 明确列出的 roadmap 包括仓库修改、离线更新和布局自定义，但都标注为 in progress 或类似状态。仓库修改功能意味着你可以直接编辑软件源，这听起来实用，但 pacman 本身也支持通过配置文件修改仓库，Shelly 的图形化实现需要等发布。离线更新功能参考的是 pacman-offline 脚本，这适合无网络环境，但开发状态未知。布局自定义是 UI 层的需求，对 CLI 用户没有意义。这些未完成功能提醒你，Shelly 当前版本 v3.1.1 只覆盖了基础包管理、AUR 和可选 Flatpak。如果你需要仓库级管理或离线更新，现在还不是切换的时候。
维护成本：GPL-3.0 和频繁的 release 节奏
Shelly 采用 GPL-3.0 许可证，这意味着如果你修改代码并分发，必须开源你的修改。对个人用户没有影响，但如果你在企业环境集成 Shelly，需要评估法律义务。发布时间线显示 v3.1.1 在 2026-08-26 发布，v3.1.0 在 2026-08-25，v3.0.6 在 2026-08-14，间隔从一天到十一天不等。这种高频发布说明项目处于活跃开发期，但也是维护负担。每次升级都可能改变 CLI 行为或配置文件格式。文档提到 Flatpak 后端有版本升级流程，但基础包没有类似的兼容性承诺。如果你用 AUR 安装，每次更新都要重新编译，而 makepkg -si 需要你本地有 zig 和 vala。相比之下，CachyOS 仓库提供预编译包，但你需要信任第三方仓库的二进制。
编辑结论
Shelly 适合两类人：一是想要图形化包管理界面的 Arch 新手，二是愿意接受新工具链的终端用户。不适合追求最小依赖或对 pacman 已有深度脚本依赖的人，因为 Shelly 的 CLI 输出和配置格式与 pacman 不兼容。采用前先验证三件事：确认你的发行版能通过 CachyOS 仓库或 AUR 安装 shelly，检查 zig 0.16.0 和 vala 是否在你的构建环境可用，以及阅读 docs/flatpak-backend-abi.md 了解可选后端的 ABI 约束。Shelly 的 development 分支更新频繁，v3.1.1 到 v3.1.0 间隔不到一天，这意味着稳定版本可能落后于代码状态，生产使用前应锁定具体 release 版本。
社区笔记