Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[hasufell]

On 10/18/2015 11:18 PM, Rich Freeman wrote:
> On Sun, Oct 18, 2015 at 4:58 PM, Ulrich Mueller <ulm@g.o> 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.
>