Wouldn't it be apropriate for kdegames to be installed with owner and group games? Then would it also be apropriate to set permissions to read and execute only for user and group? Reproducible: Always Steps to Reproduce: The rational is my fathers somewhat addictive relationship with a few cardgames. Everytime a new version of kde is available, the same happens, he finds out that the games has been reactivated, and wastes entire evenings playing. He then has to ask me to deactivate the games, and it seems the most appropriate manner is to do the same as has been done in /usr/games/bin, and only let people in the games group be able to play. If the the answer to my first to questions is no, could you please add a use flag for this functionality?
Games@: this bug wants binaries from the kdegames package to belong to the games group. Is that our policy/usage elsewhere? I neither know nor have an opinion myself. These binaries live in /usr/kde/X.Y/bin, not /usr/games/bin, if that's relevant...
Since games doesn't maintain the kde-games package, I think the kde group should make the call. In the games ebuilds we generally try to make it so that only people in the games group (passwd group here) can run games. You can look in /usr/games/bin and see what the permissions we use there.
IMO, users are used to kdegames not being restricted to the games group and some of them won't figure out why the games aren't in the menu anymore. (And I want to keep existing behavior to reduce amount of bugs :-) If anyone on kde@ disagrees I won't oppose the change much...
I really can't see backwards compatibility as an overwhelimg issue, the only thing one need to change is the group. Allthough I would prefer more restrictive permissions, there's two ways to solve the problem, without breaking backward compatibility: 1. Only changing group, keeping permissions as is. 2. Changing group, and adding a USE flag, which people has to enable in order to get the more restrictive permissions. Of course the latter would be my prefference.
See Comment 3 - as this bug has been stale for a while looks like no-one disagrees with Dan.
