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 1EDAF138247 for ; Sun, 12 Oct 2014 11:38:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 93168E0B61; Sun, 12 Oct 2014 11:38:15 +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 23AAFE0B61 for ; Sun, 12 Oct 2014 11:38:15 +0000 (UTC) Received: from pomiot.lan (77-253-140-40.adsl.inetia.pl [77.253.140.40]) (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 E2BE43403F8; Sun, 12 Oct 2014 11:38:11 +0000 (UTC) Date: Sun, 12 Oct 2014 13:37:56 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: gentoo-qa@lists.gentoo.org Cc: qa@gentoo.org Subject: [gentoo-qa] Games team policies Message-ID: <20141012133756.1904e62b@pomiot.lan> 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 Linux mail X-BeenThere: gentoo-qa@lists.gentoo.org Reply-to: gentoo-qa@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/EopDuntfqDh2YFeNfdeHfch"; protocol="application/pgp-signature" X-Archives-Salt: 8451d653-f510-4a99-83bf-a56f16476fbc X-Archives-Hash: d54869e1631d86c5012016988663403c --Sig_/EopDuntfqDh2YFeNfdeHfch Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable 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, |=20 | 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, |=20 | 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=3Duserpriv [4]. |=20 | 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. |=20 | 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. |=20 | 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). |=20 | 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=3D125902 [4]:https://bugs.gentoo.org/show_bug.cgi?id=3D516576 --=20 Best regards, Micha=B3 G=F3rny --Sig_/EopDuntfqDh2YFeNfdeHfch Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUOmgYXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOJtkQAI0q4If5m2UloS+cirR3mP+f o7U2os5B/xL7f2imCrNAW1AxWBa8jnlTFYbGRACSts6b7LNBw53WUajoWCj5Hd91 H5lvG0LnzQ/oKIDMPW5slupCoz0vuAgqFyhTu98YJscUUadvL7ybMiuZ6CO0Wcvu WnxmlzmB8HrJGoFNuY7y8adLOUHjSj6HojJlvMoyRseLFQULTx7QY3L27Qexm97h M/bOZib1yIwMuarTHWMTDwJhQe0/32ra5K865a7gDrDW1TNd2N/W+Qls1pQwv2Jz V6mmuhA87uTgM99Jt4EALq0Zf0Zic0DB6dm5OTrBh+i2cC6JvzRIkNMq1AGxPAZx OOoBTyiJvB7W+KjGmX9Bk4+0njoVdDcRykQ6RcjRrGRNSYDtdeEapwFTjgbJnuzL mWJtyvm5uTIiafmge8KN2U2oZ7T3DQWLK2N5YUOcerK/cLsfA2uEWdkUBccyn9OX sfOL1Elfr0XCvPuAR4e5NTPXp59ftq2erx2mNiWCRPsax5T99j+2T+iJ6zTBSxRR hwjSe51n5S+mAwlC2JoPcA4/FGBoP8k0Uf1LKgDnQDYoshwz+N0ZYwzo0fY06XBS bP2iossvnrQIr505Mo0Nm9jkDOgDZyXeFfJPTvHpdHDNuoplfvlqgXPSvDrevduB OP36tjairzpC7Io5j8dT =DNry -----END PGP SIGNATURE----- --Sig_/EopDuntfqDh2YFeNfdeHfch--