[Mourty]

Stacked on #43 (which is on #42). Merge those first, then change this one's base to main. It's on its own branch so #43's builds, which are being tested, are left alone.

Why

A Packages run's downloads were called rpm-x86_64, deb-arm64, appimage-aarch64, arch and aur. Those names said neither which file is inside nor who it's for, so picking the right one was guesswork.

What changes

• Each download is a zip named after the one file in it, with the same name the file has on a release page:

  • weir-1.4.0-1.fc44.x86_64.rpm
  • weir_1.4.0_amd64.deb
  • Weir-1.4.0-x86_64.AppImage
  • weir-1.4.0-1-x86_64.pkg.tar.zst
  • and the same for ARM.

  They stay zipped, as before.

• A table on the run's summary page says which download is for which system, and that x86_64/amd64 means an ordinary Intel or AMD computer. It also says the .zsync files and aur-recipe aren't for installing.

• An AppImage and its .zsync file are now two downloads, so each zip holds only what its name says. aur is now aur-recipe.

• The release job now runs on every build. It takes the files by type (*.{rpm,deb,AppImage,zsync,zst}), so it now:

  • checks there are two RPMs, two .debs, two AppImages with their .zsync files and one Arch package;
  • writes the checksums.

  Only a release signs and attaches the files. Before, a mistake here would first show up during a release, which then has to be deleted and published again.

• CONTRIBUTING says the same.

Release pages are unchanged: they already list the files under their full names.

Tested

• actionlint passes on the workflow.
• The download pattern is checked against these names with minimatch, the matcher download-artifact uses: every package matches, and aur-recipe doesn't.
• This PR's own Packages run is the real test: its page should show the new names and the table. Its "Release files" job gathers and counts the files without attaching anything.

---

---

Generated by Claude Code