blackbeard/wallet
1
0
Fork 0
Code Issues 27 Pull Requests Actions Packages Projects Releases 4 Wiki Activity

epic: packaging and distribution #5

New Issue
Open
opened 2026-09-15 12:35:22 +00:00 by grenade · 1 comment
grenade commented 2026-09-15 12:35:22 +00:00
Owner
Copy Link

Goal

dnf install blackbeard-wallet works on Fedora from a signed repository on our infrastructure, and the same tag produces a .deb, an AppImage, a Windows installer and a macOS disk image, all from Gitea Actions. Updates arrive through the Tauri updater with a minisign-verified manifest.

Facts the design rests on

  • monsoon already has the Fedora pattern: a spec with vendored crates (cargo vendor tarball as Source1), webkit2gtk4.1-devel and friends as BuildRequires, pre-built webview in the source tarball, custom-protocol feature to embed it. Lift it.
  • The rpm runner has rpmbuild, createrepo_c and signing; the rust-gtk3 runner has the GTK/WebKit dev libs. A release needs both.
  • tauri-bundler's rpm target is fine for a quick artifact but not distro-clean; the spec is the one we publish.
  • Fedora Workstation steers users to Flathub. A Flatpak is a follow-up, not v1.

Operator-owned decisions

  • Apple Developer account for signing and notarization, and a Windows code-signing certificate. Without them the dmg and installer ship unsigned with a documented warning. Needed before the signing child.
  • Repository host and path for the dnf repo, and the GPG key that signs it.

Definition of done

On a clean Fedora VM: add the .repo file, dnf install, launch from the application grid, see the version. Bump the workspace version, tag, watch CI publish, and see the running app offer and apply the update. The .deb installs on Ubuntu 24.04; the installer runs on Windows 11; the dmg opens on macOS 15.

## Goal `dnf install blackbeard-wallet` works on Fedora from a signed repository on our infrastructure, and the same tag produces a `.deb`, an AppImage, a Windows installer and a macOS disk image, all from Gitea Actions. Updates arrive through the Tauri updater with a minisign-verified manifest. ## Facts the design rests on - monsoon already has the Fedora pattern: a spec with vendored crates (`cargo vendor` tarball as Source1), `webkit2gtk4.1-devel` and friends as BuildRequires, pre-built webview in the source tarball, `custom-protocol` feature to embed it. Lift it. - The `rpm` runner has rpmbuild, createrepo_c and signing; the `rust-gtk3` runner has the GTK/WebKit dev libs. A release needs both. - tauri-bundler's rpm target is fine for a quick artifact but not distro-clean; the spec is the one we publish. - Fedora Workstation steers users to Flathub. A Flatpak is a follow-up, not v1. ## Operator-owned decisions - Apple Developer account for signing and notarization, and a Windows code-signing certificate. Without them the dmg and installer ship unsigned with a documented warning. **Needed before the signing child.** - Repository host and path for the dnf repo, and the GPG key that signs it. ## Definition of done On a clean Fedora VM: add the `.repo` file, `dnf install`, launch from the application grid, see the version. Bump the workspace version, tag, watch CI publish, and see the running app offer and apply the update. The `.deb` installs on Ubuntu 24.04; the installer runs on Windows 11; the dmg opens on macOS 15.
grenade added the epic label 2026-09-15 12:38:45 +00:00
grenade commented 2026-09-15 12:42:38 +00:00
Author
Owner
Copy Link

Children, in dependency order: #32 (release workflow) → #33 (Fedora RPM and signed dnf repo), #34 (Windows and macOS builders, signing) → #35 (updater). Operator decisions on #33 (repo host, GPG key) and #34 (Apple and Windows signing identities) are needed before those start.

Children, in dependency order: #32 (release workflow) → #33 (Fedora RPM and signed dnf repo), #34 (Windows and macOS builders, signing) → #35 (updater). Operator decisions on #33 (repo host, GPG key) and #34 (Apple and Windows signing identities) are needed before those start.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
child
One independently mergeable, verifiable step of an epic
 epic
A goal with an external definition of done; decomposes into child issues in dependency order
No Label epic
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
grenade
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: blackbeard/wallet#5
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?