From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 2209613877A for ; Wed, 30 Jul 2014 07:26:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B1DFCE07E0; Wed, 30 Jul 2014 07:26:29 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C8791E07D5 for ; Wed, 30 Jul 2014 07:26:28 +0000 (UTC) Received: from pomiot.lan (87-205-65-151.adsl.inetia.pl [87.205.65.151]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 9C815340190; Wed, 30 Jul 2014 07:26:26 +0000 (UTC) Date: Wed, 30 Jul 2014 09:26:38 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: Ulrich Mueller Cc: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2014-08-12 Message-ID: <20140730092638.5c6335d1@pomiot.lan> In-Reply-To: <21463.26330.847055.224071@a1i15.kph.uni-mainz.de> References: <21463.26330.847055.224071@a1i15.kph.uni-mainz.de> Organization: Gentoo X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/plbQqbLqtX0WQf=2qtYkKlK"; protocol="application/pgp-signature" X-Archives-Salt: 1f84ee41-937e-40cf-bd7a-a19ff516cc4e X-Archives-Hash: ce928da684133aba51c4fa1af81c443f --Sig_/plbQqbLqtX0WQf=2qtYkKlK Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Dnia 2014-07-29, o godz. 11:18:18 Ulrich Mueller napisa=B3(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. >=20 > 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=20 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=3Duserpriv [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=3D125902 [4]:https://bugs.gentoo.org/show_bug.cgi?id=3D516576 --=20 Best regards, Micha=B3 G=F3rny --Sig_/plbQqbLqtX0WQf=2qtYkKlK Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJT2J40XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOBuwP/i4F7INPm/NTeBSgjBiLMdcD r/OxjvqRsuA7NNeZAOrVPf+ZhiXJCs/FBAhBnr6aNFM8YTx+ufjfxuyik/wL3M5r V0Mxkbb5xB0hZkGBICzOqjULiAy1rESyDKtmgs+VIMA8b4cGdvLrPvEgKmGhcjTz Qnw+02ynlUJkWBO6krZ/aDclgsGNdHB/6J0PreCxigp5kV4xW/voSncQbJY55DQj o9P6OnI/2rcsrmzBqcHaYRT7vSSVd82HcG0uldv5g9Z0nAHsI0g+QP7SMOLJtO8N PpiJKqRTKuVOpeFGyR11l5xP6taM5a8y4jKPSFNJozPBq39umjwwWFROFMTxJf9K rzfwuvKrQ8pqo8z13UHHpJdv6sZKxtAtdfK9twg8NVf6HBkCVOF5+Uqys2i3bEIr xMj4N02npoQPFVS7lsvT6qVCJ7+T6BEcMdAMyCWPoZ3SfnPooVQGSERyrt3CjAKp 8jrQkHxIicvNicmbYHUtWw/yUbXEW3Vk3TeiViqERppZXa2xPcTXLqAxLOOTFc2F kGh/sOQhibc+xioA5MSnFTyldry3iaiMUeyowuUvyk5n9dMhcVtczqltVwOQSZwx R2AWgyhXJzBRXt8p/i4YlPt6xOleUdWDc9ZRI9Jd1tW3Nn0W0QWc3PfqAvVsL3FE c1TMi6Azwc6EFFwfT47z =duzX -----END PGP SIGNATURE----- --Sig_/plbQqbLqtX0WQf=2qtYkKlK--