SIGs/Games/Packaging

= Fedora Games Packaging guidelines =

In addition to the standard Packaging/Guidelines, there are a few other strong recommendations when packaging games.


 * Package game files and data files separately, if possible, to reduce size of bugfix updates. This must be done if upstream packages game data in separate tarballs.
 * In most cases, game data packages (levels, artwork, sounds and music) should be
 * Data files (maps, pixmaps, sounds) go in, not  .  Binaries go in   and not  .  According to the FHS, the use of   and   is optional, and we recommend not using either for consistency, so that games are packaged like all other applications.
 * high score and runtime configuration files should go in  according to the FHS.  If the package only puts a single file in this location, then it's acceptable to drop the %{name} subdirectory and place the file directly into /var/games.
 * man pages for games go in section 6:  according to the FHS.
 * spec file group:
 * Desktop file category:  and any from this list  as appropriate. See this mail  for info on how todo this properly.
 * License file must be included to clarify legal status, even if upstream doesn't provide it in the source tarball.
 * Game service daemons, such as those provided by xpilot-ng-server and wesnoth, must run under their own userid, not 'root', 'games', or any other system user.
 * All  must be owned by root,root, with the exception of certain shared files such as a scoreboard.
 * If necessary, a game can be made setgid 'games' in order to allow a shared scoreboard file. But only if necessary, and care should be taken to drop setgid privileges when not needed.  The following example shows how to properly drop setuid/setgid privileges.
 * 1) !cplusplus

/* Keep a global pointer to the scoreboard file. I know, global vars are extern FILE *scoreboard_filehandle;
 * ugly and should be avoided. Your application might do this differently.
 * This is just an example.

/* int main(int argc, char **argv) { gid_t realgid; uid_t realuid;
 * 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.

/* Open the scoreboard file. This could be NULL! Users of this scoreboard_filehandle=fopen(SCOREBOARDFILE, "r+");
 * 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.
 * after reading it or you won't be able to write to it again.

/* 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... */

1. creates a directory for the game in the user's home 1. populates it with symlinks to the files in the game dir under /usr/share/%{name} 1. cd into that dir and run the real binary Such a script could look like this : 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 "$@"
 * Some games are not designed for Linux/Unix : they run from a single directory, and try to write in it. A good solution for this is to create a bash wrapper which:
 * 1) !/bin/sh

OpenGL Wrapper
What you must do is: 1. Add: 1. Add to : ln -s opengl-game-wrapper.sh $RPM_BUILD_ROOT%{_bindir}/%{name}-wrapper 1. Add  to  1. Change the .desktop file Exec entry from  } to
 * If a game requires 3D accelerated graphic card you have to use DRI checking wrapper which will show an error dialog if DRI is not available explaining about Free Software and 3D drivers and then exit.

This all assumes your main binary name == %{name}, otherwise adapt as necessary.

If you already have a wrapper script for one reason or the other, you can incorperate the checkDriOk function directly into your wrapper, no need todo a wrapper wrapper, see vegastrike's vegastrike-wrapper.sh CVS file as example.

Games Documentation
After importing a game, there are a couple of extra steps that you should take:


 * Add a documentation page to the  Games wiki page
 * Add an entry to the games group in comps/comps-fe5.xml.in in cvs