Skip to content

Distribution: add a convergent TrainerOS installer for SteamOS and Bazzite #118

Description

@EriArk

Product decision

TrainerOS should no longer treat the prepared ArmadaOS image as the only supported public delivery form.

The product is the canonical TrainerOS gaming environment, usable on supported handhelds and with a TV / ten-foot presentation profile (#156–#159). A user should be able to reach that same software environment in two supported ways:

  1. flash a prepared TrainerOS/ArmadaOS image that is already in the canonical state;
  2. run a supported installer on an existing SteamOS or Bazzite handheld and let it converge that host to the same TrainerOS state.

The installer is not a lightweight launcher install and not a compatibility layer around arbitrary host emulator configurations. Its job is to create the same controlled TrainerOS session/runtime environment that the image provides.

This supersedes #70's old "image is the only supported product boundary" decision while preserving #70 as the ready-image delivery path.

User outcome

A supported SteamOS/Bazzite owner should be able to run one installer and end with:

  • a separate TrainerOS session selectable beside the host's normal gaming/desktop sessions;
  • the normal TrainerOS shell, Home behavior and controller-first UX;
  • the TrainerOS-managed emulator/runtime set at the versions expected by that release;
  • TrainerOS patches and integration hooks applied to TrainerOS-owned runtimes;
  • the same multiplayer, save, Social, Link and launch/return capabilities as the equivalent image where the hardware supports them;
  • a health/repair path that can restore TrainerOS-owned state after host updates;
  • an uninstall path that removes TrainerOS-owned components without deleting user games, firmware, saves or the host OS.

The user should not need to understand cores, emulator package variants, Gamescope command lines or patch sets to obtain a supported TrainerOS environment.

Canonical-state model

Treat the result as convergence toward one release definition rather than as a pile of installation scripts.

Conceptually:

                    TrainerOS release
                          │
            ┌─────────────┴─────────────┐
            │                           │
      prepared image              convergence installer
            │                     SteamOS / Bazzite
            └─────────────┬─────────────┘
                          ↓
                canonical TrainerOS state

Image creation, installation, software update and repair consume the same TrainerOS Software S release/runtime ownership data (#119/#153/#154). The prepared Linux image has its own I identity and update channel (#70/#71); SteamOS/Bazzite retain external host H updates. OddCrate content updates remain separate.

Host ownership boundary

Do not convert SteamOS/Bazzite into a fragile fork of itself.

Prefer TrainerOS-owned files, sessions, user services and runtime trees over modifying arbitrary user-installed emulators in place. Host-specific privileged changes must be narrow, declared and reversible.

Existing Steam/Bazzite/desktop functionality should remain available outside the TrainerOS session.

Relationship to existing work

This epic composes rather than replaces:

Those issues should evolve around a shared canonical release state instead of assuming that only a flashed ArmadaOS image can be supported.

Acceptance

  • A supported SteamOS device can be brought from a normal host installation to a selectable, usable TrainerOS session without reflashing the host.
  • A supported Bazzite device can do the same.
  • The installed TrainerOS environment uses the release's owned runtime/session stack rather than silently inheriting arbitrary incompatible emulator versions.
  • Normal host gaming/desktop sessions remain usable.
  • TrainerOS-owned state can be audited and repaired after a host update.
  • TrainerOS can be removed without deleting user ROMs, firmware, saves or unrelated host applications.
  • The same TrainerOS Software release S describes both paths; their Linux base/image/host identities may differ and update independently.
  • Differences caused by hardware/host capabilities are explicit; the installer must not fake equivalence where the host cannot provide a required feature.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions