Investigate Linux package distribution via `apt` for `keystone-cli`

[lex57ukr]

Goal

Evaluate what is required to distribute keystone-cli via Linux apt / apt-get, similar to Homebrew support on macOS, using the existing public release artifacts.

Scope

• Survey common approaches for apt-based distribution, including:
  • Hosting a custom apt repository (e.g., via GitHub Pages or static hosting)
  • Using .deb packages generated from existing release artifacts
• Identify required components:
  • Package format (.deb)
  • Repository metadata (Packages, Release, signing)
  • Hosting and update strategy
• Assess automation options:
  • How package generation would fit into the existing release workflow
  • Whether signing is required or optional for the intended use
• Document the trade-offs:
  • Setup complexity vs. maintenance cost
  • Suitability for internal vs. public consumption

Outcome

• A documented recommendation on whether apt support is practical and worthwhile
• A high-level implementation plan if pursued (repo structure, tooling, automation)
• Follow-up implementation issues defined (if applicable)

Notes

• Existing public release artifacts are already available and versioned.
• Primary motivation is internal use:
  • scripting keystone-cli in Docker-based Keystone builds
  • improving reproducibility and ease of installation in Linux environments
• This is exploratory; no implementation is required as part of this issue.

[lex57ukr]

Triage

Intent

This is an exploratory issue only. The goal is to understand feasibility and maintenance cost before committing to Linux package distribution via apt.

Recommended next steps

1. Start with a lightweight survey:
   • How .deb packages could be produced from existing release artifacts
   • What minimal tooling is required (e.g., dpkg-deb, reprepro, or similar)
2. Assess hosting options for an apt repository:
   • GitHub Pages or other static hosting
   • Whether package signing is required for the intended use
3. Evaluate automation fit:
   • How apt packaging could integrate with the existing tag-driven release workflow
4. Decide on scope:
   • Internal-only (Docker / Keystone builds)
   • Public-facing support (higher maintenance cost)

Notes

• No implementation is required as part of this issue.
• If pursued, follow-up work should be split into small, focused issues (packaging, hosting, automation).

[lex57ukr]

Investigation complete. Proceeding with apt distribution — see #48 and #49 for implementation.