openSUSE:Pacchettizzazione giochi

(Reindirizzamento da openSUSE:Packaging Games)


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:

  1. crea una directory per il gioco nella home dell'utente
  2. la popola con i collegamenti ai file nella directory /usr/share/%{name}
  3. 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 猫:

  1. Aggiungi: Requires: opengl-games-utils
  2. Aggiungi a %install:
     ln -s opengl-game-wrapper.sh $RPM_BUILD_ROOT%{_bindir}/%{name}-wrapper
  3. Aggiungi %{_bindir}/%{name}-wrapper a %files
  4. 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.