Gameshell ecosystem?


#1

hi !

just released pingu and gs.dread.fr custom debian repo

repo server allow your gameshell install dedicated packages using standard system update tools

pingu his a package manager, it list packages from custom repo
and allow you to install or remove them without technical need.

the .txt in the compo entrie forget a piece of thing for the setup, so just use this single line installer :

sudo su - -c "curl gs.dread.fr/setup | bash && apt-get install gs-pingu -y"

the pingu launcher will be found on utils folder


what’s now ?

in a first, keep calm, do not send me tons of packages to add until we do not have a community point of view on the packaging policies & future of software ecosystem.

clockwork & current launcher are great but have made some choice we can reconsider now if need,

current file system disposition force us to have dedicated icons & sh by package,

in a first, mechanics of apt install/remove will not be happy if we move the link in the menu, also i’m not thinking that’s the job of the package to force location of launch script
also as we see some people make some custom icons for a single title

apt rigidity will be incompatible with user menu customization necessity,
so, i think we need fully separate software from launch links,

what could be done now ?

on a first, we could edict a packaging policie to force all packages sh & icons to setup in a common standard location,
ask pingu to request a menu directory after setup to write real links in menu

in the long run ?

some community driven tools & packages could be done,

  • icons/programs/links manager
  • icons public database
  • event patcher to fix the pad as a keyboard issue
  • new launcher(s)
  • better packaging (categories, …)
  • drivers/launchers packages …
  • clean a bit the official rom, no more hard setup

some of the real needs are common and could be pretty found on a single project

what are your points of view ?


#2

what a great idea! I would love to contribute in anyways you think i could.


#3

Really awesome initiative!

I have a few questions about this:

Is this a Debian Private Package Archive? This doesn’t look like one but I could be wrong here. GameShell is running a Debian based distribution, and the package manager is dpkg, which has support for private repositories (PPA) so I think we should go with that.

I’m not sure if I understand this point:

apt rigidity will be incompatible with user menu customization necessity

Are you saying that APT is not a good choice for user customisation? Can you elaborate on the APT limitations for this?


#4

@duckyvirus i think there will be some step, first we need resume what is available on gameshell, forum can bury things pretty fast, a nice thread with all productions done could be very helpful

after, we need some packagers, i made a small amount of packages for this startup but i cannot maintain myself all the gs packages in the long run

for the others projects we need some talk or some code, but a bunch can be done just now, like public icons database

@Ruenzuo yes it’s a classic ppa, server files are generated using reprepro.
setup add gpg server key into the system and add the repo in sources.list

as a .deb is just a tar who will uncompress on root of filesystem it’s pretty rigid,
of course a script can be run on post install but yet i not call this flexible,

user menu disposition is fixed by clockwork : indie games, emulators, tools …
does this is ok for all users ? i think not
for now we doesn’t have tons of programs so it’s ok but when we’ll get some it will be a mess with some right button push to select good entry
i think a full customization is a need,
that’s why i propose a setup of packages in commons locations and additionally a software layer to manage links & icons into (for now) launcher menu location.

all of that is valid for real gameshell programs, other programs who need an engine like pico8 may work differently,
for now clockwork hard install engines in the os, so “rom” location is fixed but yet we need in future packages for all engines, and see at this moment if we append or not engine’s roms into the repo (like pico8 who got himself it’s own package manager ?)

that’s why yet i push in the repo only three compo games, others are not binary


#5

I’m a 20+ year linux user with Deb Ian as my preferred most of that time (I shamefully started with slackware) so if you come up with anything I can do to help I’ll be all over it.


#6

Arch for the win !!!

that’s pretty great ! you must know the system and how it’s work much better than me,
here i just done minimal things to got a workable state and certainly made some errors.

any help or advice will be greatly appreciated :sunny:

. - - . - - . - - .

for guys who want submit their own packages you could use this minimal tutorial :

download this archive : http://gs.dread.fr/gs-dstar.tar.gz
uncrunch it, you will find theses files :

[gs@dread gs-dstar]$ find .
.
./DEBIAN
./DEBIAN/postinst
./DEBIAN/control
./home
./home/cpi
./home/cpi/games
./home/cpi/games/dstar
./home/cpi/apps
./home/cpi/apps/Menu
./home/cpi/apps/Menu/21_Indie Games
./home/cpi/apps/Menu/21_Indie Games/dstar.png
./home/cpi/apps/Menu/21_Indie Games/dstar.sh

(here we see that menu entry is hard writed, a big problem on my eyes)

DEBIAN folder is a need, it will contain package info & specific scripts

others files & folder will be data to copy in the system on setup, in this example we see it will only put files in /home/cpi/

DEBIAN folder got here two files control and postinst

control file is a need, containing package information, in this minimal example here is the content :

Package: gs-dstar
Version: 19.3.14.gameJam
Maintainer: r- <r@dude.pm>
Architecture: armhf
Priority: optional
Section: games
Description: catch all sky stars !

(version MUST start with a number and pingu will ignore for now multiline description

postinst is an optional script who will be executed after setup, in dstar i’m only change ownership of sh launch script, but on jazz jack rabbit by example it will download and extract shareware data too :

#!/bin/bash
cd /home/cpi/games/openjazz/
echo "downloading shareware data"
wget -nc https://image.dosgamesarchive.com/games/jazz.zip
unzip jazz.zip
rm -f jazz.zip
chown cpi:cpi /home/cpi/apps/Menu/OpenJazz.sh

(and i’m a sucky packager as i’m not made a prerm script to delete this additional data ;- )

so, to write your own packages you need :

a top folder named with your package name (i conventionally force prefix it with gs-)
inside it all files & folder to append to the target system from root ( / ),
a DEBIAN folder with control file and optionally some script to execute

when all is nice change directory (cd) to the same level of your package top folder and ask dpkg to convert it to a .deb

dpkg-deb -b gs-dstar .

this will create a .deb file named with package name, version & architechture : gs-dstar_19.3.14.gameJam_armhf.deb

transfer the .deb file to your handled using rsync or whatever and try a manual install :

sudo dpkg -i gs-dstar_19.3.14.gameJam_armhf.deb

try remove it using package name :

sudo dpkg -r gs-dstar

if all is ok, release it, in a second time i’ll append it to the repo for making it available through apt-get

for more information on packaging check these debian pages >
https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html
https://www.debian.org/doc/debian-policy/ch-controlfields.html

as a last word, don’t miss chmod +x your scripts and take care about ownership of files, as i’m generate deb files on my server userid will differ from the cpi user of your gameshell, here i need change ownership of sh launch script in postinstall, if you generate deb files from gameshell i think userid will be correct one