Aurelien Bompard wrote:
I have made a package of Glest (http://www.glest.org
). However, something
bothers me. I've made the following layout :
/usr/libexec/glest/glest (game binary)
/usr/share/glest/ (game directory, where the rest of the files are)
/usr/share/glest/glest -> /usr/libexec/glest/glest (symlink)
/usr/bin/glest (script to run the real binary after cd'ing in the proper
This works, but on startup, the executable logs its activity in a log file
located in the same directory as the executable (/usr/share/glest)
This file has to be writable. Currently, my quick and drity fix was to
replace this file with a symlink to /tmp/glest.log.
What would the proper fix be ? I could symlink it to a /var/games/glest
directory which would be chmod 1777, but how can I make sure that two users
on the same machine can play ?
I think the proper fix would be to have glest look for a log file in
~/.glest/glest.log instead, but I'm not a C coder (sadly)...
Anyone has guidelines on how to do this ?
The fact that this package wants to run from a single dir, and write
there too, means it clearly wasn't designed for Linux from scratch. I'm
sure I can fix the log file issue at C-code level for you, but I think
we then will see similar problems with for example saving settings like
resolutions video details, etc. A good solution for this would be to
create a bash wrapper which:
1) creates ~/.glest
2) populates it with symlinks to the files under /usr/share/glest and
3) cd into that dir and run the real binary
Then you can also drop the symlinks to /usr/libexec/glest/glest from
This has 2 advantages:
1) It will also work for any other files glest will try to write to disk
to its cwd, like settings
2) Since this can be done in bash you can do it yourself and thus also
effectivly maintain it
(and 3) then I don't have to write a patch for the C-code)
Very good to hear that someone is working on packaging glest BTW!