On Fri, 11 Aug 2017 16:31:09 +0200 Axel Beckert <a...@debian.org> wrote:
> Sean Whitton wrote:
> > The latest version of the FHS does not have /usr/games, so merging this
> > with the bug about updating our FHS version.
>
> Meh.
>
> From my point of view we should continue to keep /usr/games/ for games
> as that helps to distinguish games from tools with the same name —
> which occassionally is necessary.
Whether we merge the two or not, I would argue that we should have
policy about packages not having the same binary name in /usr/games and
{,/usr}/{,s}bin , just as we now have policy about file conflicts
between / and /usr.
> Most prominent case: pacman — on the one hand the well-known game and
> on the other hand ArchLinux's package manager which is not (yet)
> packaged for Debian, but referred to in several tools packaged for
> Debian.
>
> Removing /usr/games/ from Debian would reopen the following two bugs
> without trivial solutions, i.e. requiring to explicitly remove
> upstream code instead of just removing /usr/games/ from $PATH.
>
> * neofetch: Starts the game pacman upon invocation
> (https://bugs.debian.org/845629)
>
> * needrestart: bug-script runs /usr/games/pacman when trying to use
> ArchLinux's pacman package manager /etc/needrestart/hook.d/30-pacman
> (https://bugs.debian.org/752114)
We could also fix these by renaming /usr/games/pacman. It doesn't seem
*completely* unreasonable to probe for "pacman" as the Arch package
manager, any more than probing for "dpkg" or "apt".
But at the same time, having a compile-time option to compile out
support for other package managers, and not installing hooks for other
package managers, seems reasonable as well.
