Linux: install and update Revue from a package manager (apt, dnf, pacman/AUR, Nix) #74

Closed
opened 2026-11-12 12:58:39 +01:00 by thatrichan · 3 comments
Owner

Today Linux gets a tarball (revue-vX.Y.Z-linux-x86_64.tar.gz with task install) and a flake. Users of every distribution should be able to install Revue with their package manager and get updates through it too.

Plan

1. Build the packages from the release binary

  • Add packaging/nfpm.yaml (nfpm, one static binary): one file builds .deb, .rpm and Arch .pkg.tar.zst from the binary release:build:linux already makes in rust:1-bookworm (glibc 2.36, so Debian 12+, Ubuntu 22.04+, Fedora and Arch all work).
  • Contents: /usr/bin/revue, revue.desktop (check it has MimeType=x-scheme-handler/revue; so revue:// links work without registering in Settings), hicolor icons, licenses.
  • Dependencies: take them from the binary's NEEDED entries (objdump -p), then map them to package names for each format: libxkbcommon(-x11), wayland, vulkan loader, libxcb, fontconfig, freetype, alsa, zstd. Add git too. Recommend gh.
  • Extend task package PLATFORM=linux to also write the three files, each with a .sha256.

2. Host apt, dnf and pacman repositories on our own Forgejo

Forgejo (16 here) has built-in Debian, RPM and Arch package registries, and it signs them with its own GPG key. That gives us real repositories with no extra infrastructure:

  • New task release:publish:linux: PUT each package to /api/packages/thatrichan/{debian,rpm,arch}/…. Call it from release.yml's linux job after the upload. It needs a token with write:package: either widen RELEASE_TOKEN or add a PACKAGE_TOKEN.
  • Users get apt install revue, dnf install revue and pacman -S revue (after adding the repo once), and updates come with the system's own.

3. AUR: revue-bin

  • A PKGBUILD template that installs from the release tarball, with its sha256. Have a task write the PKGBUILD and .SRCINFO from a template, because makepkg --printsrcinfo needs Arch.
  • Push to ssh://aur@aur.archlinux.org/revue-bin.git from release.yml, with a dedicated SSH key as the secret AUR_SSH_KEY. The name revue is free on the AUR. Later, a revue source package if anyone asks.

4. Nix

  • The flake already works (nix profile install). Check that task version:* bumps flake.nix.
  • Submit pkgs/by-name/re/revue to nixpkgs (based on the flake's derivation) so NixOS users get it without the flake. That makes us maintainers there, and the version bumps become PRs to nixpkgs.

5. The in-app updater must leave packaged installs alone

/usr/bin/revue belongs to root and the package manager. Self-updating it fails, or makes it disagree with the package database.

  • Generalize update::managed_by_nix() (src/update.rs:72, used in src/ui/updater.rs, app.rs, settings.rs) into "managed by a package manager": in the Nix store, or the executable's directory isn't writable by the user. This is a general check, with no list of distribution paths.
  • The update banner and Settings then say to update with the system's package manager instead of offering Update now. Test it with generic temp paths.

6. Docs

docs/getting-started.md (Install on Linux: one short block each for apt, dnf, pacman and the AUR, plus Nix), the install table in README.md, and docs/updates.md.

Not now (and why)

  • Flathub: needs a source build with vendored crates, and the sandbox gets in the way of what Revue does (runs git, gh and language servers from the host, clones into any folder). Reconsider if users ask.
  • AppImage: easy, but the tarball already covers it, and the self-updater handles it the same.
  • Snap, aarch64: no demand yet.

Decisions for you

  • Use Forgejo's registries for apt/dnf/pacman (recommended), or only the AUR plus the tarball?
  • Submit to nixpkgs and maintain it there, or keep only the flake?
  • A separate PACKAGE_TOKEN, or widen RELEASE_TOKEN?

Order

5 (updater) → 1 → 2 → 3 → 6 → 4.

Today Linux gets a tarball (`revue-vX.Y.Z-linux-x86_64.tar.gz` with `task install`) and a flake. Users of every distribution should be able to install Revue with their package manager and get updates through it too. ## Plan ### 1. Build the packages from the release binary - Add `packaging/nfpm.yaml` ([nfpm](https://nfpm.goreleaser.com/), one static binary): one file builds **.deb**, **.rpm** and **Arch .pkg.tar.zst** from the binary `release:build:linux` already makes in `rust:1-bookworm` (glibc 2.36, so Debian 12+, Ubuntu 22.04+, Fedora and Arch all work). - Contents: `/usr/bin/revue`, `revue.desktop` (check it has `MimeType=x-scheme-handler/revue;` so `revue://` links work without registering in Settings), hicolor icons, licenses. - Dependencies: take them from the binary's `NEEDED` entries (`objdump -p`), then map them to package names for each format: libxkbcommon(-x11), wayland, vulkan loader, libxcb, fontconfig, freetype, alsa, zstd. Add `git` too. Recommend `gh`. - Extend `task package PLATFORM=linux` to also write the three files, each with a `.sha256`. ### 2. Host apt, dnf and pacman repositories on our own Forgejo Forgejo (16 here) has built-in **Debian, RPM and Arch package registries**, and it signs them with its own GPG key. That gives us real repositories with no extra infrastructure: - New task `release:publish:linux`: PUT each package to `/api/packages/thatrichan/{debian,rpm,arch}/…`. Call it from `release.yml`'s `linux` job after the upload. It needs a token with `write:package`: either widen `RELEASE_TOKEN` or add a `PACKAGE_TOKEN`. - Users get `apt install revue`, `dnf install revue` and `pacman -S revue` (after adding the repo once), and updates come with the system's own. ### 3. AUR: `revue-bin` - A `PKGBUILD` template that installs from the release tarball, with its sha256. Have a task write the `PKGBUILD` and `.SRCINFO` from a template, because `makepkg --printsrcinfo` needs Arch. - Push to `ssh://aur@aur.archlinux.org/revue-bin.git` from `release.yml`, with a dedicated SSH key as the secret `AUR_SSH_KEY`. The name `revue` is free on the AUR. Later, a `revue` source package if anyone asks. ### 4. Nix - The flake already works (`nix profile install`). Check that `task version:*` bumps `flake.nix`. - Submit `pkgs/by-name/re/revue` to nixpkgs (based on the flake's derivation) so NixOS users get it without the flake. That makes us maintainers there, and the version bumps become PRs to nixpkgs. ### 5. The in-app updater must leave packaged installs alone `/usr/bin/revue` belongs to root and the package manager. Self-updating it fails, or makes it disagree with the package database. - Generalize `update::managed_by_nix()` (`src/update.rs:72`, used in `src/ui/updater.rs`, `app.rs`, `settings.rs`) into "managed by a package manager": in the Nix store, **or** the executable's directory isn't writable by the user. This is a general check, with no list of distribution paths. - The update banner and Settings then say to update with the system's package manager instead of offering **Update now**. Test it with generic temp paths. ### 6. Docs `docs/getting-started.md` (Install on Linux: one short block each for apt, dnf, pacman and the AUR, plus Nix), the install table in `README.md`, and `docs/updates.md`. ### Not now (and why) - **Flathub**: needs a source build with vendored crates, and the sandbox gets in the way of what Revue does (runs `git`, `gh` and language servers from the host, clones into any folder). Reconsider if users ask. - **AppImage**: easy, but the tarball already covers it, and the self-updater handles it the same. - **Snap**, **aarch64**: no demand yet. ## Decisions for you - Use Forgejo's registries for apt/dnf/pacman (recommended), or only the AUR plus the tarball? - Submit to nixpkgs and maintain it there, or keep only the flake? - A separate `PACKAGE_TOKEN`, or widen `RELEASE_TOKEN`? ## Order 5 (updater) → 1 → 2 → 3 → 6 → 4.
Author
Owner

AUR registration is paused (a wave of automated sign-ups, no date given), so step 3 (revue-bin) waits until it reopens. Arch users are covered in the meantime by the Forgejo Arch registry (pacman -S revue after adding the repo). Going ahead with 1, 2, 5 and 6.

AUR registration is paused (a wave of automated sign-ups, no date given), so step 3 (`revue-bin`) waits until it reopens. Arch users are covered in the meantime by the Forgejo Arch registry (`pacman -S revue` after adding the repo). Going ahead with 1, 2, 5 and 6.
Author
Owner
  • Packages and publishing: branch worktree-linux-packages (11d68ae). It builds .deb/.rpm/Arch with nfpm, publishes them to the Forgejo registries with task release:publish:linux (secret PACKAGE_TOKEN), and leaves installs Revue can't write to (/usr/bin, Nix) to their package manager. Not merged yet.
  • nixpkgs: https://github.com/NixOS/nixpkgs/pull/587188 (revue: init at 0.42.0). Later versions will come from the r-ryantm update bot.
- Packages and publishing: branch `worktree-linux-packages` (11d68ae). It builds .deb/.rpm/Arch with nfpm, publishes them to the Forgejo registries with `task release:publish:linux` (secret `PACKAGE_TOKEN`), and leaves installs Revue can't write to (`/usr/bin`, Nix) to their package manager. Not merged yet. - nixpkgs: https://github.com/NixOS/nixpkgs/pull/587188 (`revue: init at 0.42.0`). Later versions will come from the r-ryantm update bot.
Author
Owner

Shipped in 83a0975 (with the fix in ffb2899), released in v0.43.x: .deb/.rpm/Arch packages published to the Forgejo registries, and the updater leaves installs it can't write to (/usr/bin, Nix) to the package manager. nixpkgs is in review (NixOS/nixpkgs#587188). What's left, the AUR revue-bin once registration reopens, is tracked in #77. Closing.

Shipped in 83a0975 (with the fix in ffb2899), released in v0.43.x: .deb/.rpm/Arch packages published to the Forgejo registries, and the updater leaves installs it can't write to (`/usr/bin`, Nix) to the package manager. nixpkgs is in review (NixOS/nixpkgs#587188). What's left, the AUR `revue-bin` once registration reopens, is tracked in #77. Closing.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
thatrichan/revue#74
No description provided.