[gentoo-qa] Games team policies

[Michał Górny]

Hello, QA.

Since it seems that we are unable to get a proper meeting anytime soon,
I would like to discuss the agenda items of my interest via the mailing
list. For a first thread, I would like to discuss games team policies.

The specific policies were proposed for Council meeting [1, pts. 3-5],
yet the Council deferred the topic to QA as a more appropriate body
[2, 'Games team policies']:

| - There is consensus amongst council members that specific policies
|   (e.g., games group, /usr/games hierarchy, and games.eclass) should
|   be settled by the QA team.

The relevant requests are [from 1]:

| 3. the use of group 'games' to control access to games can be
| deprecated and needs not to be enforced,
| 
| 4. the /usr/games hierarchy (esp. Gentoo-specific /usr/games/lib*)
| and other locations listed in games.eclass are entirely optional. Using
| upstream install locations is recommended,
| 
| 5. the use of games.eclass is entirely optional. Preferably, the eclass
| would be deprecated since it mostly serves the purpose of enforcing
| the rules objected in (3) and (4).

And the relevant part of rationale:

| 3. The attempt of limiting access to games through use of 'games' group
| is unjustified and unprofessional. It caused multiple issues
| in the past, including repeatedly ignored security issue from 2006 [3]
| and multiple uses of RESTRICT=userpriv [4].
| 
| I recall hearing that game access ought to be restricted because
| the games are more likely to be of worse quality and the sysadmin wants
| limit the access to them to the trusted users. Yet at the same time
| the restriction is causing game ebuilds to run game tools with root
| privileges since otherwise the portage user is unable to access them.
| 
| 4. This specific hierarchy is specified by FHS as optional and is
| not beneficial to users (esp. considering the objection in (3)).
| In some cases, it forces a lot of patching on packages using
| non-autoconf build systems that would otherwise be installed in /usr
| hierarchy, with no visible benefit. Additionally, this causes Gentoo to
| diverge from upstream and therefore from other distributions.
| 
| 5. Most of the code in the games.eclass is meant to redefine phase
| functions and provide wrappers over standard PMS helpers. The sole
| purpose of all that is to force the ownership and permissions (objected
| in (3)), and /usr/games hierarchy (objected in (4)). If Council agrees
| on abolishing those requirements, the eclass becomes mostly a no-op
| (or equivalent to base.eclass which it is inheriting).
| 
| Moreover, the games team currently requires the eclass to be always
| inherited last. Since it redefines multiple phase functions, this
| sometimes results in ebuilds needing to restore all 'original' phase
| functions.

What are your thoughts?

[1]:http://article.gmane.org/gmane.linux.gentoo.project/3919
[2]:http://www.gentoo.org/proj/en/council/meeting-logs/20140812-summary.txt
[3]:https://bugs.gentoo.org/show_bug.cgi?id=125902
[4]:https://bugs.gentoo.org/show_bug.cgi?id=516576

-- 
Best regards,
Michał Górny