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

[hasufell <hasufell@gentoo.org>]

On 10/18/2015 11:28 PM, Michał Górny wrote:
> On Sun, 18 Oct 2015 22:58:31 +0200
> Ulrich Mueller <ulm@gentoo.org> 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.
>>
>> 1. Keep status quo:
>>
>>    /usr/games/bin     games binaries
>>    /usr/games/lib*    games libraries
>>    /usr/share/games   static games data
>>    /etc/games         games configuration
>>    /var/games         variable game data
>>    /var/log/games     games logs
> 
> This is no longer 'status quo', rather 'past status quo' which is
> slowly removed in favor of whatever upstream uses.
> 

Exactly.

>> 2. Change all locations that are not conforming to FHS 3.0:
>>
>>    /usr/bin           games binaries
>>    Rationale: The FHS has /usr/games as an optional directory for
>>    binaries, but we cannot use it because it is blocked by the current
>>    directory layout with /usr/games/{bin,lib*}.
>>
>>    /usr/lib*          games libraries
>>
>>    /usr/share         static games data
>>    Rationale: The FHS also allows an optional /usr/share/games but its
>>    description says "Static data files for /usr/games". So if the
>>    binaries are installed in /usr/bin then (as I read it) the data
>>    should go to /usr/share (i.e., to /usr/share/${PN} really).
> 
> I'd say we shouldn't take FHS this strongly, and use whatever upstream
> uses. If upstream uses /usr/share/games, so be it. If it
> uses /usr/share directly, so be it. Otherwise, we end up patching stuff
> and unnecessary patching is no fun at all. I still remember how much
> code I had to patch to make random games comply to 'gentoo' locations.
> 

Patching was probably in more than 90% of the cases not related to the
fact that we install into /usr/games and friends, but into eclass
variables that can be overridden by the user and that was/is a supported
games.eclass feature.

Installing consistently into /usr/bin, /usr/lib* and /usr/share will
require little to no patching, I am pretty sure of that. I converted
probably more than half of all games ebuilds to use these directories in
an overlay and all I did was removing patches and --prefix=foo lines.
It will also be consistent and not interfere with the old layout (as ulm
said, we cannot install into /usr/games), so transition will be safe.

But for /usr/share specifically we could indeed be a bit more lax. So
people should prefer /usr/share, but if it requires patching, they can
just go with /usr/share/games. But I did not hit that case yet.