Prove signed XBPS installation and immediate updates through Gitea. Changes: - Add scripts/xbps-publish.sh for automated XBPS publication - Add Makefile targets: package-xbps, sign-xbps, xbps-publish - Add docs/spec/xbps-proof-results.md with acceptance criteria results - Add docs/adr/0008-native-void-support.md (architecture decision) - Add docs/spec/native-void-support.md (feature specification) - Add docs/spec/native-void-tickets.md (implementation tickets) Proof results: - Raw URL delivery verified (no LFS indirection) - Signing key handling established (SSH RSA via xbps-rindex) - Install and update flow demonstrated (v0.3.5 → v0.3.6) - Cache behavior documented (6-hour max-age, -S flag for immediate discovery) - Publication mechanism documented and automated - Failure recovery demonstrated (git revert) Repository: https://git.bongbetic.com/xavierk/Fenris-xbps Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
72 lines
4.9 KiB
Markdown
72 lines
4.9 KiB
Markdown
# Native Void implementation tickets
|
||
|
||
Status: Approved and published as Gitea issues 83–87 with native blocking edges and ready-for-agent labels. Parent specification: https://git.bongbetic.com/xavierk/Fenris/issues/82.
|
||
|
||
Each issue references the published native Void specification, which includes ADR 0008. Existing Debian/RPM behavior, observation-history preservation, narrowly scoped privilege, and independent publication gates apply throughout.
|
||
|
||
Published tickets: [1](https://git.bongbetic.com/xavierk/Fenris/issues/83), [2](https://git.bongbetic.com/xavierk/Fenris/issues/84), [3](https://git.bongbetic.com/xavierk/Fenris/issues/85), [4](https://git.bongbetic.com/xavierk/Fenris/issues/86), [5](https://git.bongbetic.com/xavierk/Fenris/issues/87).
|
||
|
||
## 1. Prove signed XBPS installation and immediate updates through Gitea
|
||
|
||
Blocked by: None.
|
||
|
||
Deliver a dedicated public Gitea distribution repository and a repeatable, isolated XBPS-client proof using clearly identified test artifacts, without representing them as a validated Fenris release.
|
||
|
||
- Verify permanent raw URL delivery of index, package and signature bytes without LFS indirection.
|
||
- Establish signing-key handling and trust verification without exposing private keys.
|
||
- Demonstrate install and update with a client that fetched the old index immediately before publication.
|
||
- Resolve actual cache behavior and verify binary size limits; escalate any hosting change outside the agreed Gitea scope.
|
||
- Publish index/artifacts together with serialized updates, preserve older downloadable artifacts, and demonstrate safe failure recovery.
|
||
- Record results and the usable publication mechanism for subsequent tickets.
|
||
|
||
## 2. Run and control Fenris monitoring natively under runit
|
||
|
||
Blocked by: None.
|
||
|
||
Deliver an end-to-end native monitoring path with existing CLI/TUI controls and truthful status in an isolated Void environment.
|
||
|
||
- Scheduled and on-demand collection use the same acquisition path with no overlap and bounded execution.
|
||
- Preserve cadence, initial boot delay, recovery after failures, and no catch-up semantics.
|
||
- Resume/pause preserve monitoring-period bookkeeping and boot/runtime distinctions; raw service stops do not record deliberate disable.
|
||
- Verify effective authentication and actionable native diagnostics, including missing-agent failures.
|
||
- Preserve systemd behavior and application feature parity through existing public behavior tests.
|
||
|
||
## 3. Install, upgrade and remove Fenris with native XBPS packages
|
||
|
||
Blocked by: 2.
|
||
|
||
Deliver buildable x86_64/glibc XBPS artifacts with dependency resolution and tested package lifecycle in an isolated Void environment.
|
||
|
||
- Fresh install remains dormant; native controls enable monitoring afterward.
|
||
- Package ownership, configuration preservation, permissions, and group access support real CLI/TUI reads and collector writes.
|
||
- Upgrade snapshots and migrates observation history safely without recording a deliberate pause.
|
||
- Removal performs sanctioned pause and retains history; reinstall and documented snapshot rollback behave correctly.
|
||
- Installation over incompatible unmanaged remnants fails with a useful migration path.
|
||
- Capture explicit lifecycle test results and verify Debian/RPM regressions relevant to changed packaging.
|
||
|
||
## 4. Publish validated package formats independently from the release workflow
|
||
|
||
Blocked by: 1, 3.
|
||
|
||
Deliver a release workflow that builds, validates, signs and publishes XBPS alongside existing Debian/RPM support with independent format gates.
|
||
|
||
- Unvalidated formats remain withheld while validated formats can ship.
|
||
- Notes accurately identify available and withheld formats; source version, notes, checksums and artifacts agree.
|
||
- A withheld format can be added after validation without replacing existing published artifacts.
|
||
- Gitea serves every download; XBPS uses the proven permanent repository URL and immediate-refresh behavior.
|
||
- Release failure/concurrency cannot expose an index referencing missing artifacts or erase the prior usable channel.
|
||
- Host acceptance remains a required XBPS release gate, not bypassed by build/signature success.
|
||
|
||
## 5. Validate and release on the user's Void machine
|
||
|
||
Blocked by: 4.
|
||
|
||
Deliver recorded host acceptance and the validated XBPS release, ending with Fenris installed and monitoring.
|
||
|
||
- Recheck host state, identify/configure the intended NVMe drive, and preserve pre-existing data before package lifecycle operations.
|
||
- Verify real acquisition, authenticated controls, scheduling, failure reporting, full dashboard behavior, and pause/resume semantics.
|
||
- Coordinate and verify reboot persistence; absence of the reboot test leaves that gate pending.
|
||
- Verify native upgrade/removal/reinstall with history preservation and immediate update discovery through Gitea.
|
||
- Publish only after the XBPS gate passes, then verify downloads and released-package installation.
|
||
- Preserve acceptance-test observation history and leave the released package monitoring; document installation, trust setup, diagnostics and rollback for Void users.
|