Files

T

mr.zeroandClaude Opus 5 24ece3cb35 Move the stores into a stores org, and record what it took

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>

2026-08-18 08:33:36 +02:00

10 KiB

Raw Blame History

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:

linux_arm64 (és ha kell, linux_armhf) felvétele a KINDS-be és a platformok ci_platforms mátrixába.
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.
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

~~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.
~~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.
~~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.
~~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.
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.

10 KiB Raw Blame History