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 50DC513877A for ; Sat, 2 Aug 2014 11:53:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 79C8EE093E; Sat, 2 Aug 2014 11:53: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 D328DE0938 for ; Sat, 2 Aug 2014 11:53:14 +0000 (UTC) Received: from 127.0.0.1 (tor-exit.critical.cat [46.182.106.190]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: hasufell) by smtp.gentoo.org (Postfix) with ESMTPSA id 8079D34001B for ; Sat, 2 Aug 2014 11:53:13 +0000 (UTC) Message-ID: <53DCD123.2040809@gentoo.org> Date: Sat, 02 Aug 2014 11:53:07 +0000 From: hasufell 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 To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2014-08-12 References: <21463.26330.847055.224071@a1i15.kph.uni-mainz.de> <20140730092638.5c6335d1@pomiot.lan> <53D8C8D0.9070001@gentoo.org> <20140730154428.4c736e6811a22de2d7fc8d1d@gmail.com> <53D8F7C5.3070803@gentoo.org> <20140731113651.f3ed39ac883ee35bc31920d6@gmail.com> <20140802120157.60a62665@pomiot.lan> In-Reply-To: <20140802120157.60a62665@pomiot.lan> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit X-Archives-Salt: 4c782af2-5cfd-4377-be03-bf12aa6d3ead X-Archives-Hash: fae11fc3fdbc8ebf57d1f376cca9a72e Michał Górny: > > That said, cross-distribution compatibility is important. To be honest, this is a minor case and you shouldn't expect the council to do anything about it. Last time it really made a difference was about the pkgconfig discussion and neither QA nor the council cared enough to enforce consistent rules about it. No one cares about cross-distro compatibility. The more important argument is simplicity imo and maintenance burden. We are not just talking about games supposed to install into /usr/games/bin, but literally in any location, since those games variables are modifiable and advertised as such (so this wasn't really about FHS compliance in the first place). Please look at the downstream patches, sed hacks, symlink workarounds, wrapper scripts and eclasses (even gnome-games.eclass) that were introduced because of this. Sure, it's doable, but still a lot of work to support a corner case. In paludis, if you want to modify permissions for all games globally, you could easily do so via an ebuild phase hook, e.g. # cat /etc/paludis/hooks/ebuild_install_post/games_perms.bash if [[ ${CATEGORY} =~ "games" ]] ; then find /var/tmp/paludis/${CATEGORY}-${PF}/image/usr/bin -type f ... fi I'm not sure why this case has to be supported via an eclass.