ci feature: Serve .rpm / .deb through package-manager friendly repositories

[weavermarquez]

The Problem

I want to help linux users stay up to date automatically. Right now, we release .deb and .rpm files through github releases, which requires manual steps for both installation and updating. Bleh.

Proposed solution: GH releases –> Repo service

Either

a) modify README to get users to use Reprox repo which handles everything; or
b) set up some other service like github-apt-repos to serve that repo.

Reprox is the easiest and would only be a README change.

Reprox Cons:

• Reprox is a new project by one person.
• Possible MITM vuln. Reprox also includes info on how to self-host. The Reprox page also includes info on how to replicate the same repo feature using cloudflare workers.

Reprox Pros:

• signs repo metadata itself
• requires ZERO infra from maintainer, only documentation info
• redirects downloads to github's CDN, so no duplication

Quick test: works on fedora silverblue and on fedora & ubuntu distrobox containers.

  rpm repo metadata is live:
  $ curl -sf https://reprox.dev/cjpais/Handy/repodata/primary.xml.gz | gunzip | grep -E '<name>|<version' | head -6
      <name>handy</name>
      <version epoch="0" ver="0.8.0" rel="1"/>
      <name>handy</name>
      <version epoch="0" ver="0.8.0" rel="1"/>
      <name>handy</name>
      <version epoch="0" ver="0.7.12" rel="1"/>

  deb install resolves from reprox (ubuntu 24.04 container):
  $ apt-get update 2>&1 | grep reprox
  Get:5 https://reprox.dev/cjpais/Handy stable InRelease [1636 B]
  Get:6 https://reprox.dev/cjpais/Handy stable/main amd64 Packages [3145 B]

  $ apt-get install -s handy | grep "^Inst handy"
  Inst handy (0.8.0 Handy:stable [amd64])

  rpm-ostree on silverblue (my actual machine):
  $ rpm-ostree status | grep -A2 LayeredPackages
            LayeredPackages: gtk-layer-shell handy waydroid wtype

Alternatives:

• Some other GH -> rpm/deb repo not listed. The above is from a cursory search.

• Publish the deb/rpm repository here. Before submitting this discussion and finding reprox I prepped a fork with a github workflow that downloaded release RPMs/DEBs and published them as dnf/apt repositories on GitHub Pages. However, I wasn't happy with using 1.3GB per run and felt it made this a little bit less forkable.

• I've considered helping out with a flatpak release. Similar apps like Whis on flathub have stuck to the copy-paste only approach. But even with a system-wide Handy install I had to make a custom script to get the talk-to-computer-and-auto-paste feature working. See my Handy setup & custom script

• deb/rpm on official repos or alternatives like COPR / PPA. Unfortunately these channels don't accept the pre-built binaries Tauri already handles. See Appendix below

Appendix: abridged convo w Claire (transfem claude)

> ❯ So why isn't it easy thru official repos / copr / ppa if tauri already handles it all?                              

● bc official repos / copr / ppa don't accept pre-built binaries. they require source → build in THEIR environment.

  it doesn't matter that tauri can produce a .rpm on github actions. copr/koji/launchpad want to:

  1. take your source code + .spec file
  2. spin up a clean chroot with nothing but base packages
  3. install build dependencies
  4. run the build themselves
  5. package the result

  so you'd need a .spec that does bun install && bun run tauri build inside copr's mock environment. which means copr
  needs to have (or you need to bootstrap): rust toolchain, bun, node, webkit dev headers, all the tauri native deps,
  GPU headers for vulkan, etc. most of these aren't in fedora's repos in the exact versions needed, or need specific
  feature flags.

❯ Shouldn't there be templates for that sort of stuff anyways?
                                                      
● honestly, yeah. "tauri app → fedora copr" should be a solved problem by now given how many tauri/electron apps
  exist. but it's not, bc:

  - tauri is relatively young (v2 shipped mid-2024) and the linux packaging story has been secondary to mac/windows
  - copr/koji don't have a "rust + node/bun hybrid" build template — they have rust templates and node templates
  separately, but the combo is on you to wire up
  - the bun situation is especially bad — bun isn't packaged in any major distro repo, so you'd need to bootstrap it
  in the build environment
  - electron has the same problem — almost no electron apps are in official repos for this exact reason. they all ship
   via flatpak, snap, or self-hosted repos