On 06/29/2016 10:11 AM, Michał Górny wrote:
> Hello, everyone.
> 
> Over half a year has passed since Council decided upon the fate of
> games in Gentoo. Over that period, the games team has neither showed
> any will to respect the Council decisions, nor officially appealed to
> them.
> 
> For this reason, the QA team would like to officially start supporting
> the migration of ebuilds out of games.eclass. Any developer wishing to
> help is more than welcome to take any games.eclass ebuild, bump its
> revision and remove the games.eclass-specific bits from it. Updating to
> EAPI 6 would also be welcome. A short update guide is provided at
> the end of mail.
> 
> Please note that since this is considered a matter of QA action with
> a long waiting period, no explicit approval from games team is
> necessary to commit the conversion, nor games team is allowed to reject
> or revert such commits as long as they are valid.
> 
> If you need any help doing that and the games team refuses to provide
> it, please do not hesitate to contact me or ask in #gentoo-qa. If you
> are interested in helping out with games, feel free to join games team
> since it still lacks new members.
> 
> Thank you for all the help.
> 
> 
> Migration notes
> ---------------
> 
> TL;DR: nothing special required, remove games.eclass and all
> unnecessary games.eclass customization, and follow upstream. Make sure
> not to break stuff.
> 
> 
> The Council decisions can be summarized the following way:
> 
> 1. The 'games' group, formerly used to control access to games, must
> not be used. Games should be executable for all users like any other
> program [1].
> 
> 1a. For score files and similar writable shared data, the 'gamestat'
> group (enewgroup gamestat 36) can be used. The old 'games' group is not
> appropriate since sysadmins were expected to add users to it which
> defeated its purpose.
> 
> 2. Gentoo path customization for games must be removed and regular
> install locations (without explicit control via GAMES_* variables)
> should be used [2]:
> 
> 2a. /usr/games and /etc/games directories are forbidden,
> 
> 2b. /usr/share/games can be used for data if that directory is used
> upstream,
> 
> 2c. /var/games can be used for shared writable data.
> 
> 
> This is mostly achieved through removing games.eclass inherit,
> customization specific to it and replacing the helpers with generic PMS
> helpers (e.g. egamesconf -> econf, dogamesbin -> dobin).
> The 'gamesowners', 'gamesperms', 'prepgamesdirs' calls should be
> removed altogether.
> 
> In some cases it will also be beneficial to remove patching added to
> support non-standard locations.
> 
> Please remember to always rev-bump and not edit in place, to ensure
> proper upgrade. When dealing with dependencies, please make sure to
> check if the package does not rely on dependency installing data in
> a specific location. If that is the case, then you need to use
> appropriate >= deps to ensure clean upgrade.
> 
> If you would like to report bugs requesting games.eclass removal,
> please make them block the tracker [3].
> 
> 
> [1]:https://projects.gentoo.org/council/meeting-logs/20151011-summary.txt
> [2]:https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt
> [3]:https://bugs.gentoo.org/show_bug.cgi?id=574082
> 
I'm glad to see some reach-out here and taking responsibility for
decisions. However, what does the QA team have to say about systems that
want games on other media (such as an SSD or separate HDD), or wish to
restrict the use of games on their system to certain accounts?

Bumping EAPI won't magically allow those to happen, and removing the
eclass *will* break those use cases. What's the "blessed" way to do those?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to