mr.zeroandClaude Opus 5
24ece3cb35
The `tools` definition — "one person installs and runs it for themselves" — stopped
describing the store engines: they are products other people can build on. So the
four store repositories left `tools` for a `stores` org of their own, and the org
map, the clone list, the wiki table and the ecosystem plan follow. `check-repos.sh`
is green at 49.
Worth writing down for the next org change: `tea` has no transfer subcommand, but
`tea api` makes authenticated calls with tea's own credentials, which is enough for
all of it — POST /orgs, POST /orgs/{org}/teams, PUT /teams/{id}/members/{user},
POST /repos/{owner}/{repo}/transfer. And the transfer keeps Gitea's redirect: the
old `tools/...` raw URLs answer 301, so the installers on already-configured boxes
did not break. That is why this was a transfer and not a migrate-and-delete.
`warpstore` stayed in `engines`: it is a library other repos depend on, which is
what that org is for. The launcher gap moved out of the tools chapter of
ECOSYSTEM_PLAN into the new stores one, where it belongs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
140 lines
10 KiB
Markdown
140 lines
10 KiB
Markdown
# 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), `stores/warp-engine-retroarch-store`
|
|
(motor), `stores/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.
|