Re: [gentoo-project] Call for agenda items - Council meeting 2014-08-12

["Michał Górny" <mgorny@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4486 bytes --]

Dnia 2014-07-29, o godz. 11:18:18
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> In two weeks from now, the council will meet again. This is the time
> to raise and prepare items that the council should put on the agenda
> to discuss or vote on.
> 
> Please respond to this message with agenda items. Do not hesitate to
> repeat your agenda item here with a pointer if you previously
> suggested one (since the last meeting).

Following my earlier mail to gentoo-dev [1], I would like the Council to
either abolish the specific policies enforced by games team, or confirm
that they are non-binding.

The games team is currently (against the structure given by GLEP 39
[2]) claiming itself to have sole and complete authority over every
game package in Gentoo. Additionally, it tries to fit them in 
a Gentoo-specific model that causes many games to diverge from upstream
and gain a lot of unnecessary complexity, sometimes even causing
security issues.

I have tried to convince the games team to consider changing
the policies multiple times, sometimes getting rude responses or no
reply at all. At this point, I believe that the only solution is to
ask the Council to clarify the policies which can be enforced
by a single team.

More specifically, I would like the Council to appropriately confirm or
establish that:

1. every developer is allowed to commit and maintain game ebuilds,
without the need to ask for permission or review from games team,

2. games team does not have authority to override maintainer decisions
on game packages,

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).


Rationale
---------

1. Game packages do not include core system packages or packages
otherwise critical to Gentoo. They also do not have any common pitfalls
specific only to games that could justify the requirement of review.
Being an active Gentoo developer should be the only necessary quality
required to commit game ebuilds.

2. Since no special treatment is justified, the games team should not
claim the right to override maintainer's decisions, remove maintainers
or remove packages stating 'non-games team commit' as a reason.

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.

[1]:http://thread.gmane.org/gmane.linux.gentoo.devel/91839/
[2]:https://wiki.gentoo.org/wiki/GLEP:39
[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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]