Provide a signed openSUSE repository for one-command native installation

[dskvr]

Follow-up to #34. openSUSE users currently download an RPM plus checksum/signature material before invoking Zypper. Provide a maintained signed repository so, after a documented one-time bootstrap, installation is sudo zypper install loopwire and updates use the documented Zypper workflow.

Initial scope: openSUSE Tumbleweed, x86_64. Leap and additional architectures need separate package/guest validation. Retain the signed automatic installer as a fallback. The publication provider is still a decision: OBS or a project-owned Zypper repository.

Development implementation and evidence: #47. The production channel remains pending; the Human operational tasks below are unchanged and unchecked.

Development tasks

• Evaluate and document the publishing approach. Compare OBS with project-owned hosting for Tumbleweed compatibility, signed packages/metadata, release promotion, retention, and rebuild behavior. Recommend an approach and record its configuration/credential requirements, including how stable publication waits for validation.
• Implement the chosen package path. For project-owned hosting, reuse packaging/rpm/opensuse-tumbleweed.spec.in and scripts/build-rpm-package.sh. For OBS, add the project/package build configuration and release-tag/source inputs. Record source revision and build IDs, and verify the final OBS-produced RPM rather than reusing proof from a different package build.
• Implement and verify RPM/repository signing. Validate provider-managed package and metadata signatures, or implement signing for project-owned hosting. Finalize RPM signing before recording final checksums and package evidence. Publish the public key/fingerprint needed for client trust.
• Implement staged publication and rollback. Promote only a complete, tested package/metadata revision, retain a previous installable version, and make retries idempotent. For OBS, explicitly configure build/publish/release controls so rebuilds do not silently replace the verified stable output. Document rollback and recovery from partial publication.
• Integrate protected release automation. Trigger the selected publication path after existing artifact gates, wait for provider build/signing/publication completion where applicable, and fail on incomplete work. Add CI coverage for the new inputs and a fixture/dry-run path without production credentials.
• Provide a tested Zypper bootstrap. Document adding the correct Tumbleweed repository, verifying its signing-key fingerprint, and refreshing metadata. Preserve package/metadata signature checks; do not use --no-gpg-checks or --allow-unsigned-rpm for this repository path. Document repeat-safe setup, repository removal, key changes, and package vendor/priority behavior.
• Add repository regression tests. Reject unsigned/tampered RPMs and metadata or a wrong key; validate architecture/version selection, retry behavior, and rollback. Include an OBS rebuild/publish failure case if OBS is selected.
• Add Tumbleweed lifecycle and compatibility tests. On a clean supported Tumbleweed guest, test repository install, reinstall, upgrade from an older published version, removal, and rollback with the final distributed RPMs. Record the tested Tumbleweed snapshot, package origin/vendor, signatures, GUI/provider smoke results, and logs. Add a repeatable compatibility check for later Tumbleweed snapshots and a policy for incompatible updates.
• Update user and maintainer documentation after public verification. Update the openSUSE homepage tab, install guide, support matrix, release guide, and unreleased notes. Separate bootstrap from sudo zypper install loopwire, document the tested update procedure and rolling-release limitations, and retain the automatic-installer fallback. Identify the repository as third-party; do not imply default-distribution availability.

Human operational tasks

These require maintainer access to provider accounts, signing material, or GitHub settings. Tooling and fixture tests can proceed before production access exists.

• Select the provider and responsible maintainer. Use the development recommendation to choose OBS or project-owned hosting; record the project identifier/public URL and the initial Tumbleweed x86_64 target.
• Provision the selected service. For OBS, create/access the account and project, configure its Tumbleweed repository/architecture and maintainer permissions, and apply the agreed publication controls. For project-owned hosting, provision storage, HTTPS/DNS as needed, staging/production locations, and scoped upload access.
• Establish signing and recovery ownership. Verify and record the OBS project's public signing key/fingerprint and key-change procedure, or provision a self-managed OpenPGP key with backup/rotation. Provider-managed private keys remain with the provider.
• Configure the protected GitHub environment. Add the OBS/API or storage credentials and public project/URL settings required by the publisher; add private signing material only for self-managed signing. Confirm that the release workflow has the intended access.
• Complete the first production publication and assign ongoing coverage. Run the tested publication workflow and clean-guest check against the public repository. Attach the workflow/provider build IDs, repository URL, fingerprint, tested Tumbleweed snapshot, installed version, and lifecycle logs. Assign the maintainer responsible for responding to later Tumbleweed compatibility failures.

Done when: the public Tumbleweed repository serves authenticated RPMs and metadata; publication/rebuild promotion is controlled and recoverable; published-artifact lifecycle/tamper tests pass; and the homepage/docs reflect the tested bootstrap and Zypper workflow. Joining existing download commands into one line does not meet the goal.

Provider reference: OBS build, signing, and repository publication. Related channels: #35 and #36; share applicable RPM signing/repository tooling with #36 while preserving openSUSE-specific recipes, vendor behavior, and guest proof.