Chris Hofstaedtler wrote: > Nevertheless I think the generic text is a good idea. After all, > what good is having programs with the same name in /usr/bin and > /usr/games.
Agreed. Program name conflicts are a problem, whether between /usr/bin and /usr/sbin, or between /usr/bin and /usr/games. > I would propose the following: > > 1) for trixie, recognise that this is not an RC bug or anything. > > 2) for forky, try to merge /usr/games into /usr/bin. +1. This would also eliminate arguments over whether something is a "game" or a "tool". There are a variety of useful tools that get shipped (or formerly got shipped) in /usr/games. To bring up two things that people have brought up in the past, and address them: - People have complained that putting games in /usr/bin would result in having games on root's default path, and they weren't designed to be run as root. However, insecure applications are buggy no matter where they're installed, users shouldn't be exposed to this either (and users often access root via sudo and similar), and if this is a concern, things should be removed. - A *very* small set of users with e.g. university installations have said that they use the /usr/games separation to be able to restrict access to games. I think this is a sufficiently niche use case that such people should use things like dpkg-statoverride.
