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 00BAA13888F for ; Sun, 18 Oct 2015 22:13:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 19A08E081D; Sun, 18 Oct 2015 22:13:56 +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 82AF2E080D for ; Sun, 18 Oct 2015 22:13:54 +0000 (UTC) Received: from [192.168.0.12] (aftr-37-201-212-166.unity-media.net [37.201.212.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: hasufell) by smtp.gentoo.org (Postfix) with ESMTPSA id 1AC7934016B for ; Sun, 18 Oct 2015 22:13:50 +0000 (UTC) Subject: Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11 To: gentoo-project@lists.gentoo.org References: <1904237.nU16iSOlTl@kailua> <20151012102318.1abe5138.mgorny@gentoo.org> <22043.43688.429409.917985@a1i15.kph.uni-mainz.de> <22052.2039.578624.138664@a1i15.kph.uni-mainz.de> From: hasufell X-Enigmail-Draft-Status: N1110 Message-ID: <5624199B.7000004@gentoo.org> Date: Mon, 19 Oct 2015 00:13:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 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 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 0daee5ed-e176-46ee-8c36-0efbd26b3a89 X-Archives-Hash: ed31194a05b734cc8d9ce19c71b9e7ce On 10/18/2015 11:18 PM, Rich Freeman wrote: > On Sun, Oct 18, 2015 at 4:58 PM, Ulrich Mueller wrote: >> Following up to this. I think the choice is between the two extremes >> of keeping the status quo and of changing all non-FHS locations, or >> some intermediate solution. > > The value of keeping the status quo is that it is the status quo, IMO. > Tweaking it makes it no longer the status quo and it just means lot of > change for questionable value (again, IMO). > Not keeping status quo means: 1. less patching 2. less ebuild code 3. no misplaced menu files and friends in /usr/share/games/applications and whatnot anymore, since DATADIR and DATAROOTDIR in e.g. autotools based build systems have to be both defined to make this work (only in case upstream has a sane build system). For cmake based build systems this can be even more funny, depending on what upstream does. Installing into these games directories is actually _uncommon_ and most upstreams don't have these defaults. But it will not be that painful once someone _actually_ deprecates games.eclass, so we get rid of those GAMES_* variables that can point to arbitrary non-FHS compliant directories. These are the biggest problem. > I'd just as soon do away with the games eclass altogether if we're > going to make a change. Then games become like any other package. > That is a state I think is worth changing for. If we're just going to > move one or two directories around, I don't really see why we need to > make everybody jump through hoops, unless those few directories are > causing major problems today. > > Sometimes the compromise between two arguable positions isn't > something that makes sense to anybody. If we're going to change, > let's make sure that what we change to makes sense on its own. >