build: add RPM packaging for releases

[basil]

Objective

Make it easy for Fedora (and other RPM-based) users to install Wayle by publishing official RPM packages as part of every GitHub release, alongside the existing tar.gz archive.

Solution

• The Spec template in packaging/rpm/wayle.spec.in repackages the prebuilt upstream tarball into an RPM. Installs the binaries, wayle.service user unit, .desktop entry (validated with desktop-file-validate), app/action icons, and shell completions into the canonical FHS locations. @VERSION@/@DATE@ are substituted at build time. debug_package is disabled because the archive contains a prebuilt binary with no source to generate debuginfo from. A fallback for _userunitdir is defined since Arch's rpm-tools does not ship systemd-rpm-macros.
• We refactor archive generation into a reusable script in scripts/ci/build-archive.sh. The tarball staging logic previously lived inline in release.yml. It now lives in a script that takes <target-dir> <version> <arch>, so both CI and the release job can produce the exact same archive layout that the spec file consumes.
• We add a new package build script in scripts/ci/build-packages.sh. Given the archive and version, renders the spec from the template and runs rpmbuild -bb against a local _topdir. Keeps the packaging surface out of the workflow YAML. The file is named build-packages.sh in the plural because the idea is that hopefully some Ubuntu user will come along in the future and add a .deb package to it as well.
• We wire both jobs into the same path:
  • release.yml now calls build-archive.sh then build-packages.sh, and uploads rpmbuild/RPMS/${ARCH}/*.rpm to the release alongside the tarball. The checksums job also picks up *.rpm so SHA256SUMS covers both artifacts.
  • ci.yml runs the same two scripts on every push so the packaging path can't silently regress between releases. There should be no surprises at tag time. Added packaging/** to the path filter, and desktop-file-utils + rpm-tools to the package install step in both workflows.

Testing Done

• Built wayle-0.2.1-1.x86_64.rpm locally in an archlinux:base-devel container (same image as the release job) from the v0.2.1 release tarball. Installed on Fedora 44, started both wayle and wayle-settings. Both launch cleanly.
• CI job is green: https://github.com/basil/wayle/actions/runs/24613038926/job/71970605418
• Release job is green: https://github.com/basil/wayle/actions/runs/24613036857/job/71970600967

[Jas-SinghFSU]

Thanks! Is this meant to be a completion of #94?

[basil]

Yes, with end-to-end testing of both the build/release jobs and on my Fedora 44 system.

[PerchunPak]

Isn't it a job of a distro to package?

[basil]

Strictly speaking, yes, but that simple calculus changes a lot for Electron and Rust applications, particularly ones like this that have so many dependencies. Electron and Rust packaging in distributions is a known pain point, requiring a lot of manual labor to package each and every crate or to build Chromium from source (in the case of Electron). For applications like Wayle that use so many crates, it would take so much effort to package the program "properly" in Fedora or Ubuntu that I see little chance of this ever happening. Options then become:

• Rely on the community to produce unofficial packages. Problems with this are trust (how do you know which community package to trust?) as well as continuity (as community members stop maintaining packages under their personal namespace, how does the torch get passed)?
• The project maintains its own official repositories for various distributions. This is better for end users, as they have a trusted source of packages with continuity over time. An example of this is https://github.com/microsoft/vscode

For a project like Wayle, where an officially sanctioned package in core Fedora or Ubuntu is unrealistic and probably not achievable, I think it would be preferable for there to be official Wayle packages and repositories for the popular distributions that offer statically linked binaries, which aren't acceptable in core Fedora and Ubuntu. This PR is the first step in that direction. I'm willing to make more PRs after this to help take packaging even further:

• One next step after this PR is to improve the code further to run the package build in a different container for the target distribution.
• Adding .deb and other formats
• Publishing to a repository on GitHub Actions as in https://github.com/aaddrick/claude-desktop-debian

Ultimately I think the main goal of @Jas-SinghFSU is to reach as many users as possible, and I think that goal would be best achieved through official rather than community packaging, and since "distribution official" in Debian and Fedora is unachievable for a Rust program like this without superhuman amounts of effort, then "Wayle official" is the next best thing, and this PR is a first step in that direction.

[PerchunPak]

"distribution official" in Debian and Fedora is unachievable for a Rust program like this without superhuman amounts of effort

This sounds like a serious issue in their packaging system; in Nix we just do cargo fetch and put a hash on the result directory. But if that's how it is, LGTM

[basil]

This sounds like a serious issue in their packaging system

There's definitely an impedance mismatch between traditional Linux distribution packaging and modern Rust and Electron apps. There's a reason so many popular Rust projects are packaged for Debian/Fedora by having you run curl | sh (or a Flathub package) rather than using official upstream .deb/.rpm files. I'm not sure I would go so far to say that this is a serious issue in the distribution's packaging system, though... these are decades-old systems with a long history, huge deployment counts, and serious compatibility constraints, and newer tooling like Rust packaging or Electron applications hasn't been designed with them in mind. Although I haven't been involved in these conversations directly, my understanding is that those distribution Rust teams are looking for ways to align and collaborate better with upstream Rust (and Electron for that matter). That alignment/collaboration is a work in progress. So perhaps things may improve in the future, but we aren't there yet.

@Jas-SinghFSU Perhaps you could consider which direction you want this project to go in:

• Providing distribution packages yourself (best for Debian/Fedora users) like https://code.visualstudio.com/download - in which case I can help with PRs like this and more that build on it
• An approach like https://ghostty.org/docs/install/binary where Debian/Fedora users are left to find "community binaries" (e.g. Fedora COPR, Launchpad PPA rather than dealing with prohibitive official distribution Rust packaging policies) - in my opinion less beneficial for users, but this can be somewhat mitigated by hosting the code in the wayle-rs GitHub organization and officially linking to the preferred COPR/PPA from Wayle docs
• Some other approach entirely, like FlatHub or curl | sh (though my gut feeling is that wouldn't work too well for a shell like this) - happy to explore other options in a thread like this or even a video call if that would be more convenient

[PerchunPak]

Unfortunately, this cannot be packaged as a flatpak because

A wayland bar does not qualify as an "app".

Also, can't the user just use cargo install wayle (if wayle gets published on https://crates.io/)? Packaging this for specific distributions feels like an extra maintenance burden for downstream

Although @Jas-SinghFSU has the final say

[basil]

@PerchunPak I think we've gone back and forth on this enough for now, and I'll note that I already wrote that my gut feeling is that a Flatpak wouldn't work too well for a shell like Wayle. cargo install is one option, but that has its drawbacks as well (namely, lack of integration with OS-level dependencies, of which Wayle has several). I'll wait for Jas to comment before discussing this further, as this is a policy question that needs to be decided by the maintainer.

[justjustie]

Guess I can close #94?

[basil]

@Jas-SinghFSU Any update on this PR?