On Sun, 18 Oct 2015 22:58:31 +0200 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. > > 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. > 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. > /etc games configuration > > /var/games variable game data > Rationale: FHS section 5.7.: "Any variable data relating to games > in /usr should be placed here." > This could also be used for logs previously placed in > /var/log/games, when for some reason they cannot got to /var/log > (but AFAICS it would affect only two packages in the tree). -- Best regards, Michał Górny