The Problem

The Atomic (Reproducible) Build Approach

Why This Matters

Where the Traditional Approach Works Fine

Not a New Idea

Install Hyprland 0.55.0 just dropped with a new Lua-based config layer. Cool feature - except it requires Lua 5.5, and Fedora repos still ship Lua 5.4. I maintain a COPR for Hyprland on Fedora that bundles all hypr-* library dependencies into a single build with zero external COPR deps. This Lua situation is a textbook example of why this approach exists - and why it fits Fedora better. Hyprland was orphaned after F42 (doesn't exist in official repos). On Fedora 43 and 44 the only way to install it is through COPR repositories or building from source. Most Hyprland COPRs for Fedora follow the traditional approach inherited from solopasha's original repo: every hypr-* library (libaquamarine, libhyprlang, libhyprutils etc.) is packaged as a separate RPM with its own build cycle. That means when you dnf install hyprland, you pull in 15+ individual packages. Each one is built independently, sometimes days apart. When you dnf upgrade, each updates on its own schedule. Now add Lua 5.5 to the mix. In my COPR, Lua 5.5 is built from source with -fPIC and linked statically into the Hyprland binary. No new runtime dependency, no conflict with system Lua. The same isolation principle applies to every hypr-* library. Instead of installing libaquamarine, libhyprlang, libhyprutils etc. as separate RPMs into /usr/lib64/, they're built as shared libraries into a private vendor prefix (/usr/libexec/hyprland/vendor/lib64/) and resolved via RPATH. They never touch system library paths, so there are no conflicts with other packages and no duplicates in dnf repoquery --duplicates. With the traditional approach, there's always a window where your system is in an inconsistent state. The maintainer rebuilds aquamarine on Monday, hyprland on Wednesday - between Monday and Wednesday, users who upgraded have a mismatched ABI. The compositor might crash on launch and the user has no idea why. With vendor-clean builds, the update is atomic. One spec file builds the compositor, hyprlock, hypridle, and all library dependencies together. Everything is compiled against the same versions in the same build. It either all works or none of it ships. It's the same philosophy behind how Go produces binaries - one static file, all dependencies inside, no dependency hell at runtime. On Arch and other rolling release distros where all system libraries stay on the bleeding edge. Hyprland is officially supported on Arch, and AUR packages are built from source on the user's machine - so they link against whatever library versions are already installed. No version mismatch, no frozen dependencies. The problem is specific to point-release distros like Fedora, where system libraries are pinned to a release version. When a bleeding-edge compositor like Hyprland moves faster than the distro's package set, something has to give. On Arch, the distro keeps up. On Fedora, you need to bring the dependencies with you. This vendor-clean approach is a well-established pattern across the industry. Go is the most obvious example. go build produces a single statically linked binary with all dependencies compiled in. No shared libraries - deploy one file and it runs. The Go team made this a deliberate design choice, and it's one of the reasons Go dominates in infrastructure tooling. NixOS solves the same problem differently but with the same goal. Every package is built in isolation with its exact dependency tree, stored in /nix/store/ with a hash-based path. Two versions of the same library coexist without conflict. Hyprland is officially supported on NixOS precisely because Nix eliminates dependency hell by design. Atomic/immutable distros like Fedora Atomic, Universal Blue, and Vanilla OS take yet another approach - the entire OS image is built and tested as a unit, then deployed atomically. No partial upgrades, no inconsistent state. My COPR applies the same principle at the package level: one build, one atomic unit, all versions locked together. It's close to Nix/Go/Atomic philosophy, but implemented as an RPM spec file for a traditional Fedora install. Source and spec files: github.com/AshBuk/Hyprland-Fedora Vendor-clean Hyprland package for Fedora 43/44, currently serving 2,700+ users. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse