| 1 |
On 10/18/2015 11:28 PM, Michał Górny wrote: |
| 2 |
> On Sun, 18 Oct 2015 22:58:31 +0200 |
| 3 |
> Ulrich Mueller <ulm@g.o> wrote: |
| 4 |
> |
| 5 |
>> Following up to this. I think the choice is between the two extremes |
| 6 |
>> of keeping the status quo and of changing all non-FHS locations, or |
| 7 |
>> some intermediate solution. |
| 8 |
>> |
| 9 |
>> 1. Keep status quo: |
| 10 |
>> |
| 11 |
>> /usr/games/bin games binaries |
| 12 |
>> /usr/games/lib* games libraries |
| 13 |
>> /usr/share/games static games data |
| 14 |
>> /etc/games games configuration |
| 15 |
>> /var/games variable game data |
| 16 |
>> /var/log/games games logs |
| 17 |
> |
| 18 |
> This is no longer 'status quo', rather 'past status quo' which is |
| 19 |
> slowly removed in favor of whatever upstream uses. |
| 20 |
> |
| 21 |
|
| 22 |
Exactly. |
| 23 |
|
| 24 |
>> 2. Change all locations that are not conforming to FHS 3.0: |
| 25 |
>> |
| 26 |
>> /usr/bin games binaries |
| 27 |
>> Rationale: The FHS has /usr/games as an optional directory for |
| 28 |
>> binaries, but we cannot use it because it is blocked by the current |
| 29 |
>> directory layout with /usr/games/{bin,lib*}. |
| 30 |
>> |
| 31 |
>> /usr/lib* games libraries |
| 32 |
>> |
| 33 |
>> /usr/share static games data |
| 34 |
>> Rationale: The FHS also allows an optional /usr/share/games but its |
| 35 |
>> description says "Static data files for /usr/games". So if the |
| 36 |
>> binaries are installed in /usr/bin then (as I read it) the data |
| 37 |
>> should go to /usr/share (i.e., to /usr/share/${PN} really). |
| 38 |
> |
| 39 |
> I'd say we shouldn't take FHS this strongly, and use whatever upstream |
| 40 |
> uses. If upstream uses /usr/share/games, so be it. If it |
| 41 |
> uses /usr/share directly, so be it. Otherwise, we end up patching stuff |
| 42 |
> and unnecessary patching is no fun at all. I still remember how much |
| 43 |
> code I had to patch to make random games comply to 'gentoo' locations. |
| 44 |
> |
| 45 |
|
| 46 |
Patching was probably in more than 90% of the cases not related to the |
| 47 |
fact that we install into /usr/games and friends, but into eclass |
| 48 |
variables that can be overridden by the user and that was/is a supported |
| 49 |
games.eclass feature. |
| 50 |
|
| 51 |
Installing consistently into /usr/bin, /usr/lib* and /usr/share will |
| 52 |
require little to no patching, I am pretty sure of that. I converted |
| 53 |
probably more than half of all games ebuilds to use these directories in |
| 54 |
an overlay and all I did was removing patches and --prefix=foo lines. |
| 55 |
It will also be consistent and not interfere with the old layout (as ulm |
| 56 |
said, we cannot install into /usr/games), so transition will be safe. |
| 57 |
|
| 58 |
But for /usr/share specifically we could indeed be a bit more lax. So |
| 59 |
people should prefer /usr/share, but if it requires patching, they can |
| 60 |
just go with /usr/share/games. But I did not hit that case yet. |
Archives