On Mon, 11 Sep 2023 at 10:19:13 -0700, Russ Allbery wrote: > I am inclined to agree [with no longer recommending /usr/games]; > it's just one more thing for people to think about > while packaging things, and I don't think it serves much of a useful > purpose. However, the bug log has a couple of concrete objections.
I have another possible reason to separate /usr/games, which I think is potentially more compelling than either of the ones in the bug (I'm sorry, I thought it was already common knowledge): Games are often written for performance more than correctness, and frequently do non-ideal things or have unfixed security issues. If we separate them into /usr/games and avoid putting that directory in root's PATH, then tab completion mistakes can't result in root accidentally running a game. Similarly, I think (although I have no evidence) it's more common to install non-free games, and non-free game managers like Steam, than non-free utility/application software. If we put those in /usr/games, the root can't accidentally run those as a result of a tab-completion mistake. Entertainment programs that are not strictly games (the ones we might classify as "toys") have similar considerations. Is this enough to justify the existence of /usr/games? I don't know; but I think it's more likely to be enough to justify /usr/games than the other reasons previously cited here? In recent versions of Debian's Steam packaging (formerly the steam package, now the steam-installer package) I've put a safety-catch on it: if some important files in ~/.steam/root don't exist (indicating a new installation), the wrapper script doesn't actually install or run any proprietary code until the user has confirmed in a GUI dialog that they actually wanted to install it. Similarly, the binary-only games that game-data-packager can install have a wrapper script with a confirmation dialog before the first run, similar to a clickthrough license, to avoid accidents. That mitigates these being in privileged users' PATHs. Valve's official Steam packaging in their third-party apt repository (the steam-launcher package, currently maintained by me with a different hat on) installs to /usr/bin and has no such safety-catch, but it does require adding an apt source that will result in running Valve-supplied maintainer scripts as root, so if you add that apt source you're already completely trusting Valve anyway. > Axel Beckert objected because games may conflict with other tools > installed in /usr/bin. I feel like this is already a bug and merging the > two namespaces to force us to deal with that bug may be a feature in > disguise, because having two binaries with entirely different purposes on > the user's PATH is a recipe for confusion and problems. I agree. I think it's silly that a PATH search for pacman can result in running either a 2D maze game or Arch Linux's package manager, especially if the two packages are co-installable! I know we have a Policy requirement that packages do not contain both /bin/foo and /usr/bin/foo, to ensure that merged-/usr is possible. I thought we also had a requirement for names of executables in the PATH to be unique between /{usr/,}bin and /{usr/,}sbin, but I can't find it now. I know some packages like iproute2 install both /{usr/,}sbin/ip and /{usr/,}bin/ip, which I think is OK if they are functionally equivalent, but would be a bug if they were functionally different. > This is similar the old multiuser timeshare use case for separating games > back when they competed for resources with other uses of the system and > administrators wanted to be able to stop people from running them until > after hours. I feel like this use case is exceptionally rare at this > point, and I'm not sure it's worth the packaging thought to maintain a > separation just for that. Unlike Axel's namespace-splitting use-case, I think this is a positive thing, but I'm unsure whether its small benefit is really worth its cost. > Alexandre also requested keeping games data separate so that it could be > moved out of the /usr partition because it could be quite large. Again, I think this is a positive, but I'm unsure whether its benefit is worth its cost. Perhaps it would be proportionate to say that games MAY install into /usr/share/games, and leave it up to maintainers whether they do so, with the suggestion that small games shouldn't bother but maintainers of large games might want to consider it? Disclosure: I am a co-maintainer with Alexandre of the game-data-packager package, which installs proprietary game data into /usr/share/games, some of it much larger than the vast majority of games we package in Debian; and I think converting game-data-packager and its various supported game engines for a transition from /usr/share/foo to /usr/share/games/foo would be quite annoying to achieve, without providing any significant benefit. smcv