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
