On 2023-09-11 19:57:16, Bill Allombert wrote:
[...]
> On the other hand, /usr/games allows:
> - priviledged accounts to omit /usr/games in their path (root does not have
> it e.g)
I said it elsewhere but I'll repeat it here, if we want a separation
there, we already have another mechanism for that, and it's "private
binaries" in (say) /usr/libexec/<package>
> - quickly find which games are installed on a system (ls /usr/games).
That's neat, but I doubt most users look for installed software with
`ls`. They are way more likely to use a GUI and there we have much
better mechanisms to sort things into buckets, other than "games" and
"not games".
In fact, I will argue that this makes games *harder* to find. If, for
some bizarre reason, a normal user ends up on the commandline to start a
game, they will type "gamename" (e.g. "freeorion") and will get an
unhelpful "command not found", because /usr/games typically won't be in
their PATH.
So this makes games easier to find for an extremely narrow class of
users who browse their filesystems looking for programs, I am not sure
it's worth it.
> - have a separate partitions for game data (which are amongst the largest
> Debian package)
That, as far as I know, is not something /usr/games does at
all. e.g. here freeorion-data is all in /usr/share, not in /usr/games.
> - have a specific policy for /var/games
that also doesn't seem directly related to /usr/games, ie. you could
keep /var/games and not have /usr/games.
a.
--
La politique est l'art d'empêcher les gens de se mêler de ce qui les
regarde
- Paul Valéry
