devarea/MORE_STORES.md

# Milyen további store-okat érdemes csinálni

Készült 2026-08-16-án, a `warp-engine-batocera-store` szétválasztása után. A kérdés: a batocera-store mintájára milyen más gazdaplatformra tudnánk store-t adni.

## A mérés, ami átrendezi a kérdést

A katalógus legfrissebb kiadásaiban (15 szoftver) ennyi asset van (2026-08-17-i mérés):

| Asset | Hány szoftvernél | Ki használja ma |
|---|---|---|
| `html` | **11** | senki — a publikus oldal lejátssza, de nincs könyvtár |
| `win_x64` | **9** | senki |
| `linux_x64` | **9** | senki |
| `linux_arm64` | 1 | a batocera-store (arch-illesztéssel) |
| `cartridge` | 7 | a batocera-store |
| `win_x86` | 4 | senki |
| `mac_x64` | 3 | senki |
| `docs` / `source` | 3 / 3 | a publikus oldal |
| `mac_universal` | 2 | senki |

Platformonként:

| Platform | Elérhető assetek |
|---|---|
| c64 | `cartridge` (4) |
| tic80 | `cartridge`, `html`, `source`, `docs`, `win_x64`, `linux_x64`, `mac_x64` (3) |
| ebitengine | `html`, `win_x86`, `win_x64`, `linux_x64` (3) |
| godot | `html`, `win_x86`, `win_x64`, `linux_x64`, `mac_universal` (1) |
| love | `html`, `win_x64`, `linux_x64`, `mac_universal` (1) |
| phaser | `html` (2) |
| bevy | `html` (1) |

**A tanulság:** a batocera-store csak a `cartridge`-et fogyasztja, tehát a katalógus **7/15 részét**. A legelterjedtebb asset-fajtánk, a webes build, egyetlen store-ban sem szerepel. Nem az a szűk keresztmetszet, hogy kevés store van — hanem hogy a meglévő a katalógus felét ott hagyja.

---

## 0. Előfeltétel mindenhez: ARM Linux buildek — *kész*

*(2026-08-16-án megoldva; az alábbi indoklás megmaradt, mert a 3. és 4. pont erre épül.)*

**Akkori állapot: a build-mátrixunkban nem volt Linux ARM asset.** A `ReleaseAsset::KINDS` ezt tartalmazza:

```
cartridge source html docs
win_x86 win_x64 linux_x86 linux_x64
mac_x64 mac_arm64 mac_universal
```

Van `mac_arm64`, de **`linux_arm64` és `linux_armhf` nincs** — a `linux_x86` pedig szerepel a listán, csak épp semmi nem gyárt bele.

Ez azért döntő, mert a Batocera nem csak x86_64-en fut: Raspberry Pi-n, Odroidon és a kézikonzolokon ARM-on megy. Egy `linux_x64` bináris ezeken **feltelepül, de nem indul el** — ami rosszabb, mint ha nem is ajánlanánk fel. Ugyanez blokkolja az 1. pont legérdekesebb célpontjait: a muOS, ArkOS és JELOS kézikonzolok szinte mind ARM-osak.

Amiért a mai store hordozható: a `cartridge` **architektúra-független** (adat egy emulátornak), ezért mind a 7 cím megy minden Batocera gépen.

**Teendő, sorrendben:**
1. `linux_arm64` (és ha kell, `linux_armhf`) felvétele a `KINDS`-be és a platformok `ci_platforms` mátrixába.
2. Cross-build a pipeline-okban. A legkönnyebb az ebitengine (Go: `GOARCH=arm64`), utána a bevy (Rust cross toolchain) és a godot (van ARM export template); a LÖVE a legnehezebb, ott ARM futtatókörnyezet kell.
3. A motor **architektúra-felismerése** (`uname -m` → `x86_64` / `aarch64` / `armv7l`), és csak az illeszkedő asset telepítése.

## 0b. `linux_*` → Batocera *ports* — *kész*

*(2026-08-17-én megvalósítva a motorban.)* A ROM-rendszerek mellett van egy második telepítési mód: `install: "port"` esetén a zip kicsomagolódik, és egy `.sh` indító kerül a Ports rendszerbe. A payload a `ports/.data/<subfolder>/` alá megy — a pont rejti el az ES elől —, az indító pedig egy normál almappába, amit az ES ugyanúgy pásztáz, mint bármely más rendszerét.

Számokban, a mai assetekkel:

| Gép | Lefedettség (mérve 2026-08-17) |
|---|---|
| x86_64 Batocera | **13/15** |
| ARM Batocera | **9/15** — és nő, ahogy a repók újrafutnak az ARM pipeline-nal |

A kimaradó kettő a `phaserdemo` és a `trickster-tiles`: mindkettő csak `html`-t
ad, natív binárisuk nincs, tehát ezekhez böngésző kell — natív store soha nem
fogja őket kiszolgálni.

Ugyanez a keret adja az interaktív ES-menüt is (ports bejegyzések gamelist-metaadattal).

---

## Új store-ok, sorrendben

### 1. ES-családú store-ok
RetroPie, Recalbox, ES-DE, és a kézikonzolos disztrók (muOS, ArkOS, JELOS). Ugyanaz a `gamelist.xml` + ROM-mappa modell, amire a motor **már generikus**: gyakorlatilag `paths.roms_root`, rendszernév-leképezés és egy másik telepítő kell. A legtöbb elérés a legkevesebb munkáért. Az ES-DE Windowson és macOS-en is fut, tehát asztali elérést is ad mellékesen.

Fontos megkötés: a **kézikonzolok jóformán mind ARM-osak**, és a RetroPie is Pi-n fut. Cartridge-dzsel ezek azonnal kiszolgálhatók, natív játékkal viszont csak a 0. pont ARM buildjei után.

### 2. Asztali store — `warp-engine-desktop-store`
A per-OS zipeket telepíti egy helyi könyvtárba, és indítót csinál hozzá (`.desktop`, Start menü bejegyzés, `.app`). Ma 8 szoftvert szolgálna ki, és a CI-lefedettséggel nő. Ez a legnagyobb valóban új képesség: asztali gépre ma **semmilyen** utunk nincs.

### 3. Steam-könyvtár
A `shortcuts.vdf`-be írva a játékaink megjelennek a Steam könyvtárban borítóval — és ezzel a Steam Decken is. A letöltést a 2. pontról örökli, tehát ráépül, nem mellé megy. Bevált technika, a Heroic és a Lutris is ezt teszi.

### 4. RetroArch playlistek
`.lpl` JSON playlist platformonként. A cartridge-eket sokkal nagyobb közönségnek adja, mint a Batocera: Android, asztali gépek, konzolok. Kis formátum, kevés munka.

**Kész (2026-08-17).** Terv és mérések: `RETROARCH_STORE.md`. Három repó:
`engines/warpstore` (a kiemelt közös mag), `tools/warp-engine-retroarch-store`
(motor), `tools/ttg-retroarch-store` (a mi store-unk). A Batocera-motor ugyanabban
a körben átült a közös magra. **Hátra van:** valódi gépen kipróbálni, hogy a
VICE-mag magától indítja-e a `.prg`-t, és hogy az Android `adb push` útvonalai
állnak-e. Ott mérve: mind a két mag (`vice_x64`, `tic80`) elérhető minden célon, Androidon is; a playlist-könyvtár nem feltétlenül a RetroArch alapkönyvtárában van, tehát a `retroarch.cfg` kötelező olvasmány; a borító csak PNG lehet, amin az `impostor` GIF-je ma elhasal; leírást a `.lpl` nem tud. A motor egyetlen valódi új képessége az út-átírás (`stage_root` / `target_prefix`), ami az Androidot és a 2. pont asztali store-ját egyszerre szolgálja.

### 5. BBS store
A `bbs/bbs-server`-be, a saját `rubbs`-unkra épülve. Bármelyik asset-fajtát tudja adni letöltésként, és ez az egyetlen a listán, amit **rajtunk kívül senki nem tudna lemásolni** — márkaérték, nem csak elérés.

### 6. Csomagkezelők
Homebrew tap és Scoop bucket: `brew install ttg/tap/rabbitroller`. Kevés munka, és nem kell hozzá launchert írni; a 2. pont csomagolására épül.

### 7. Webes könyvtár / PWA
A `html` assetek megvannak, de ez van a legnagyobb átfedésben a mostani publikus oldallal, ezért a legkisebb határhasznú — annak ellenére, hogy ez a legelterjedtebb assetünk.

---

## Amit nem javaslok

- **itch.io** — az az ő katalógusuk, nem a miénk; nem store-t adnánk, hanem feltöltenénk.
- **Flatpak / Snap** — nehéz átvezetés és felülvizsgálat kevés extra elérésért.
- **Önálló Android APK** — nagy munka; a RetroArch úton (4. pont) az android elérés majdnem ingyen megvan.

---

## A minta

Mind ugyanaz a forma: **olvasd a WarpEngine katalógust → írd a gazdaplatform saját könyvtárformátumát.** A `warp-engine-batocera-store` szétválasztásával ezt már megalapoztuk. Ha a közös rész — katalógus-lekérés és gyorsítótár, kiadásválasztás (`dev-` kihagyás, asset-egyeztetés), `state.json`, borítókép, prune-védelem saját almappával — egy helyen marad, akkor egy új store valóban csak egy **adapter plusz egy config**.

Egy dolog viszont **nem** tartozik az adapterbe, hanem a közös részbe: az **architektúra-illesztés**. A gazdaplatform megmondja, milyen gépen fut (`uname -m`, Windows/macOS esetén a megfelelő megfelelője), és a motornak ehhez kell asset-fajtát választania. Ez a 0., 1. és 2. pontnak egyaránt kell, tehát egyszer, jó helyen érdemes megírni.

**A közös rész 2026-08-17-én kiemelve:** `engines/warpstore`, egyetlen fájl, amit mindkét motor a telepítéskor letölt. Benne a katalógus és gyorsítótára, a kiadásválasztás, a `state.json`, a borító-letöltés, az atomikus írás és a törlés-őr — plusz az architektúra-illesztés, ami a második adapter miatt `resolve_for_host`-tá bővült: nem csak az `arch`, hanem az `os` is kulcs lehet, mert egy libretro mag fájlneve OS-enként más. Egy új store innentől valóban egy adapter plusz egy config.

## A javasolt sorrend

1. ~~**`linux_arm64` a build-mátrixba**~~ — **kész** (2026-08-16). Az `ebitengine` és a `bevy` gyártja; a `godot`-hoz a játék repójában kell ARM export preset, a LÖVE-hoz nincs upstream ARM AppImage, a TIC-80 `export` parancsának meg nincs ARM célja. A `bevydemo` 1.0.0 már `linux_arm64`-et is ad.
2. ~~**Architektúra-illesztés a motorba**~~ — **kész** (2026-08-17). A `kind` és az `ext` lehet architektúra-leképezés `*` tartalékkal; a felismert arch látszik a `list` és a `config` kimenetében. `aarch64`-en végigpróbálva: az ARM csomagot tölti le, és a benne lévő bináris valóban AArch64.
3. ~~**`linux_*` → Batocera ports**~~ — **kész** (2026-08-17). `install: "port"`; `aarch64`-en végigpróbálva: telepítés, idempotens újraszinkron, eltávolítás a 106 MB-os payloaddal, és a névtér-védés is (idegen `.data` útra mutató bejegyzést elutasít). **Hátra van:** bekapcsolni a `ttg-batocera-store` configjában, és valódi gépen kipróbálni, hogy a natív játékok tényleg elindulnak-e.
4. ~~**RetroArch playlistek**~~ — **kész** (2026-08-17), a közös mag kiemelésével együtt. Lásd `RETROARCH_STORE.md`. **Hátra van:** a VICE `.prg`-autostart és az Android-út valódi gépen.
5. **ES-családú store-ok** (1.) — a motor itt már majdnem kész, és a `warpstore` óta az adapter tényleg csak a gazdaplatform írása.

## Amit valódi gépen kell ellenőrizni

A 2. és 3. pont azon áll vagy bukik, hogy a per-OS zipjeink **önmagukban futtathatók-e**: van-e hiányzó függőség Linuxon, és mit szól hozzá a macOS aláírás-ellenőrzése egy nem jegyzett binárishoz. Erről a katalógus nem árulkodik, csak egy próba.