Fedora装Hyprland为何得自带全套依赖

Hyprland 0.55.0刚发布，带来了基于Lua的新配置层。听起来是个不错的功能——但它需要Lua 5.5，而Fedora官方仓库还停留在Lua 5.4。

这个版本冲突，恰好解释了为什么我在Fedora上维护的Hyprland COPR要采用"vendor"模式：把所有hypr-*库依赖打包进单个构建，零外部COPR依赖。Lua 5.5的困境，就是这种方案存在的典型理由。

Hyprland在Fedora 42之后已被官方弃用，F43和F44用户只能通过COPR或源码编译安装。市面上大多数Hyprland COPR沿用了solopasha原始仓库的传统做法：每个hypr-*库（libaquamarine、libhyprlang、libhyprutils等）都作为独立RPM单独打包、单独构建。

这意味着执行dnf install hyprland时，系统会拉入15个以上独立包。每个包各自独立构建，时间可能相隔数天。dnf upgrade时，它们也按各自节奏更新。现在再把Lua 5.5加进这个局面——混乱可想而知。

我的COPR选择了另一条路：Lua 5.5从源码构建，带-fPIC参数，静态链接进Hyprland二进制文件。没有新的运行时依赖，也不与系统Lua冲突。

同样的隔离原则延伸到所有hypr-*库。传统方案把它们作为独立RPM装进/usr/lib64/，我的方案则是作为共享库构建到私有vendor前缀（/usr/libexec/hyprland/vendor/lib64/），通过RPATH解析。它们从不触碰系统库路径，因此不会与其他包冲突，dnf repoquery --duplicates也不会出现重复项。

传统方案有个结构性问题：系统总处于不一致的窗口期。维护者周一重构建了aquamarine，周三才构建hyprland——周一到周三之间，升级了aquamarine的用户就面临ABI不匹配。合成器可能启动即崩溃，用户完全摸不着头脑。

Vendor-clean构建则实现了原子化更新。单个spec文件同时构建合成器、hyprlock、hypridle及所有库依赖。所有组件在同一构建中、针对相同版本编译。要么全部可用，要么整包不发布。

这背后的理念和Go语言生成二进制文件的方式一致：单个静态文件，所有依赖内置，运行时没有依赖地狱。

Arch等滚动发行版不存在这个问题——系统库始终紧跟上游。Hyprland官方支持Arch，AUR包在用户机器上从源码构建，直接链接已安装的库版本。没有版本错配，没有冻结依赖。

但定点发行版如Fedora，系统库被锁定到特定版本。当Hyprland这种激进更新的合成器比发行版软件包移动更快时，矛盾就出现了。Arch是发行版跟上软件，Fedora则需要软件自带依赖。

这种vendor-clean方案在业界早有成熟先例，Go语言就是典型代表。