Since 3.5.0 kdegames also supports systemwide highscores. (Infact it was already supported before, but broken, then I fixed it for 3.5) I'll attach a patch to make use of it in the kdegames.ebuild. A similar patch has to be applied to the split games ebuilds then.
Created attachment 75277 [details, diff] kdegames-3.5.0.patch
Haven't touched any KDE Game(s ebuild) in a while, so.. - What's up with --with-highscore-group and --with-highscore-user? root if not set I suppose!? - Why deleting the score when upgrading? If I were a gamer, I'd be pissed if my great no. 1 highscore would be deleted.
Did anyone actually try this? Patch in comment #1 wouldn't work: kdegames-3.5.0 by default installs highscore files for these games only: (these 5 are working) - kbounce - kfouleggs - klickety - kmines - ksirtet The following games abort with an error message about a missing highscore file: - kreversi - knetwalk (manually creating these files with correct modes would fix the problem, but see below) The following games abort with the following message if suid/sgid: "The KDE libraries are not designed to run with suid privileges." - knetwalk Addtionally, it's useless to delete old highscores in pkg_preinst because any new kde version would already overwrite old scores with blank ones. Sounds like a very, very, very bad idea to me, in addition to comment #2 and #3! Merry Xmas!
sorry for the delay... a.) Yes I tested the patch, i wrote it, even commited the necessary changes to kde svn and it works here in an "production environment" b.) "--with-highscore-group and --with-highscore-user" don't know about them, didn't need them c.) it doesn't delete the highscore's on the system but the new and empty to be installed highscore files, so it preserves the highscores to be overwritten d.) strange things about kreversi and knetwalk, have to look into it
b.) --with-highscore-group should be games and --with-highscore-user should be games as well
Created attachment 80254 [details, diff] kdegames-highscore.patch patch for kreversi and knetwalk
patch will be in kde 3.5.3
(In reply to comment #4) > c.) it doesn't delete the highscore's on the system but the new and empty to be > installed highscore files, so it preserves the highscores to be overwritten Please excuse my blindness... It didn't work for me (out of the box): FATAL: cannot open global highscore file "//var/lib/games/kreversi.scores" Aborted There're a couple of points to note: - the scores files do not get created automatically - most games don't use systemwide scores at all (only seven do) - it'd be necessary to install the games --enable-setgid, lowering security a bit - using the games group does not work, since users in the games group could modify the scores files otherwise (cheat, inject malicious data to be executed by other users in the games group, if possible) - odd, seeing this with other games. -> bug 129954 - looking at the other games, the directory should be ${ROOT}/var/games
I have the eclass changes for the split ebuilds ready, but want to wait until the games herd has sorted out the permission issues.
> It didn't work for me (out of the box): > FATAL: cannot open global highscore file "//var/lib/games/kreversi.scores" > Aborted > - the scores files do not get created automatically They should, did you apply the patch? > - most games don't use systemwide scores at all (only seven do) Still an advantage for those 7 and no disadvantage for the rest > - it'd be necessary to install the games --enable-setgid, lowering security a > bit > - using the games group does not work, since users in the games group could > modify the scores files otherwise (cheat, inject malicious data to be > executed > by other users in the games group, if possible) - odd, seeing this with other > games. -> bug 129954 Either you setgid them, which should be no problem since the root privilegs are dropped very fast, or you use the games group which is the default for gnome games as well. > - looking at the other games, the directory should be ${ROOT}/var/games Looking at the other games it should be ${ROOT}/var/lib/games
(In reply to comment #10) > Either you setgid them, which should be no problem since the root privilegs are > dropped very fast, or you use the games group which is the default for gnome > games as well. Setgid to a non root group, yes. Just that it's not possible to use the games group, since all users are in the games group. And really don't want to add yet another group and have to change it again and correct user installations accordingly, once the games herd has decided which way to go. > > - looking at the other games, the directory should be ${ROOT}/var/games > Looking at the other games it should be ${ROOT}/var/lib/games Um, I just have installed trackballs and falconseye to test if the user write access to global scores is a general problem and both put their scores files in /var/games. No matter what - it should be a single directory, shouldn't it!?
I have those gnome games installed and they are in /var/lib/games, but in the end we should decide on one directory. Installing as root gid should be no problem since the code directly drops the root privilegs after reading/writing the highscore file
bugzie
4.X can use ggz. which is quite great for scores. For 3.X we set most feature requests wontfix. And it looks like split ebuilds have it correctly. Cheers.
