openSUSE:Pacchettizzazione giochi

Creazione dei pacchetti

Linee guida generali · Linee guida per i nomi · Linee guida per i file Spec · Linee guida per le patch · Linee guida per la sicurezza · Linee guida per i gruppi RPM
Guida al Build Service · Consigli e suggerimenti · Come creare pacchetti per più distribuzioni · Controlli nella creazione dei pacchetti
Categorie dei menu Desktop · Macro RPM · Scriptlet · Script Init · Come scrivere buoni file delle modifiche

Questa pagina contiene le linee guida su come pacchettizzare i videogiochi per openSUSE e altre distribuzioni usando il Build Service di openSUSE.

In aggiunta alle linee guida standard sulla pacchettizzazione, ci sono alcune altre importanti raccomandazioni quando si pacchettizzano i videogiochi.

Separazione dei pacchetti

Pacchettizzare i file di giochi e i file di dati separatamente, se possibile, per ridurre la grandezza degli aggiornamenti di risoluzione dei bug. Ciò si può fare se i pacchetti dei dati di gioco sono separati dai file di gioco.
Nella maggior parte dei casi, i pacchetti dei dati di gioco (livelli, artwork, suoni e musiche) dovrebbero essere BuildArch: noarch
I File di dati (mappe, pixmap, suoni) vanno in %{_datadir}/%{name} , non in %{_datadir}/games/%{name} . I file binari vanno in %{_bindir} e non in /usr/games. Secondo FHS, l'uso delle directory /usr/share/games e /usr/games è opzionale. Raccomandiamo di non usarle per coerenza, cosicché i giochi siano pacchettizzati come tutte le altre applicazioni.
Se sai che un gioco con la versione 1.3.3 funziona con i dati della versione 1.2 o superiore, potresti usare il seguente schema:

game.spec

Version:  1.3.3
Requires: game-data >= 1.2

game-data.spec

Version: 1.2
Requires: game >= 1.2

Librerie usate comunemente

Per i giochi che richiedono SDL usare SDL-devel (ed eventualmente altre voci simili, come SDL_image-devel, SDL_mixer-devel, SDL_net-devel, etc.) in BuildRequires. Questi simboli sono forniti dalle varie librerie SDL impacchettate da openSUSE, per cui usare direttamente libSDL-devel (nei BuildRequires) non funzionerà su Fedora, Mandriva e le vecchie versioni di openSUSE.

File e permessi

I file dei punteggi e di configurazione a runtime dovrebbero andare in /var/games/%{name} secondo la FHS. Se il pacchetto mette un solo file in questo percorso, allora si può togliere la sottodirectory %{name} e mettere i file direttamente in /var/games.
Le pagine dei manuali per i giochi vanno nella sezione 6: %{_mandir}/man6/ stando all'FHS.
Gruppo dei file spec: Group: Amusements/Games
Categoria dei file desktop: Categories=Game; e qualsiasi altra si ritenga appropriata da questa lista. Per ulteriori informazioni sull'inserimento di categorie nei file .desktop, in maniera appropriata, vedere questa mail.
I file di licenza devono essere inclusi per chiarire lo stato legale dei file, anche se in upstream non sono messi a disposizione nei tarball dei sorgenti.
I demoni dei servizi del gioco, come quelli offerti da xpilot-ng-server e wesnoth, devono essere avviati sotto la loro userid, non 'root', 'games', o qualsiasi altra usata dal sistema o dagli utenti.
Tutti i %files devono essere di proprietà di root,root, con l'eccezione di certi file condivisi come le scoreboard (tabelle dei punteggi ecc.).
Se necessario, un gioco può essere fatto in modo da essere impostato (setgid) sul gruppo 'games' e avere un file di scoreboard condiviso. Ma, ripeto, solo se necessario, con l'attenzione di rilasciare i privilegi di setgid quando necessario. Il seguente esempio mostra come fare a rilasciare i privilegi setuid/setgid in maniera appropriata. Un setgid, comunque, richiede la previa approvazione del team di sicurezza di SUSE.

/* Mantieni un puntatore globale al file della scoreboard. Lo so, 
* le variabili globali sono brutte e dovrebbero essere evitate. 
* La tua applicazione, infatti, potrebbe farlo in maniera differente. 
* Questo è solo un esempio.
*/
extern FILE *scoreboard_filehandle;

/*
* Notice that we deal with dropping setgid immediately in main() after opening
* the scoreboard file, and before doing _anything_ else.  This minimizes the amount
* of code that is run setuid/setgid.
*/
int main(int argc, char **argv) {
gid_t realgid;
uid_t realuid;

/* Open the scoreboard file.  This could be NULL!  Users of this
* variable must check before using and not bother writing a
* scoreboard if it is null.
*
* The file is opened with mode "r+" to preserve the existing contents.
* This allows the program to first read the scoreboard and then write
* it out again with new values.  Just make sure you don't close() the file
* after reading it or you won't be able to write to it again.
*/
scoreboard_filehandle=fopen(SCOREBOARDFILE, "r+");

/* Figure out who we really are.
*/
realgid = getgid();
realuid = getuid();

/* This is where we drop our setuid/setgid privileges.
*/
if (setresgid(-1, realgid, realgid) != 0) {
perror("Could not drop setgid privileges.  Aborting.");
exit(1);
}
if (setresuid(-1, realuid, realuid) != 0) {
perror("Could not drop setuid privileges.  Aborting.");
exit(1);
}
/* ...Continue setting up the game... */

Giochi non realizzati per Linux/Unix

Alcuni giochi non sono stati realizzati per Linux/Unix: si avviano da una sola directory e provano a scriverci dentro. Una buona soluzione a questo sarebbe creare un wrapper con bash che:

crea una directory per il gioco nella home dell'utente
la popola con i collegamenti ai file nella directory /usr/share/%{name}
si sposta in quella directory e avvia l'eseguibile reale

Una possibile implementazione per uno script del genere potrebbe essere la seguente:

#!/bin/sh
GAME_LOCAL_DIR=$HOME/.mygame
GAME_DATA_DIR=/usr/share/mygame
GAME_EXECUTABLE=/usr/libexec/mygame/mygame
mkdir -p $GAME_LOCAL_DIR
cd $GAME_LOCAL_DIR
for dir in techs data maps tilesets; do
ln -snf $GAME_DATA_DIR/$dir $dir
done
test -d savegames || mkdir savegames
test -e mygame.ini || cp $GAME_DATA_DIR/mygame.ini mygame.ini
exec $GAME_EXECUTABLE "$@"

OpenGL Wrapper

Se un gioco richiede una scheda dedicata all'accelerazione grafica 3D, devi usare il wrapper di verifica DRI, il quale mostrerà un errore se il DRI non è disponibile, con una spiegazione riguardante il Free Software e i driver 3D, per poi uscire. Quello che dovrai fare è:

Aggiungi: Requires: opengl-games-utils

Aggiungi a %install:

 ln -s opengl-game-wrapper.sh $RPM_BUILD_ROOT%{_bindir}/%{name}-wrapper

Aggiungi %{_bindir}/%{name}-wrapper a %files
Cambia l'entry dell'eseguibile nel file .desktop da %{name} a %{name}-wrapper

Questo assumendo che il nome della directory principale sia %{name}, altrimenti adatta come necessario.

Se, per una certa ragione, hai già lo script wrapper puoi incorporare la funzione checkDriOk direttamente nel tuo script, per esempio guarda il file vegastrike-wrapper.sh di vegastrike, come esempio.