On 2023-09-11 10:19:13, Russ Allbery wrote: [...]
> I am inclined to agree; 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. For the record, I actually read through those and didn't mean to restart that thread: I figured people made their points and argued there thing and there wasn't much to be said there, but now that you've made such a nice summary, I can expand on the opinion I voiced above, I guess. :) > 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. The two bugs > cited were: > > https://bugs.debian.org/845629 > https://bugs.debian.org/752114 > > which are about a conflict between the game pacman and the package manager > pacman. The game pacman now appears to be orphaned but does indeed still > ship /usr/games/pacman, and /usr/bin/pacman is provided by > pacman-package-manager. Yeah, I've always find this confusing, *especially* when you (like me) have been adding /usr/games to your PATH since basically forever. The truth is we really have one global binary namespace. Things that move away from that tend to generate problems, or just live in their own namespace (e.g. /usr/libexec or something). /usr/games is just a weird exception that does not, in my opinion, deserve to exist anymore. > There was also one request (from Alexandre Detiste) to retain this > separation that, if I understood it correctly, was based on wanting to > block access to games for children with accounts on the system. > > 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. I also believe there are other ways to block access to files than move them to a different directory, even if we *would* want to respond to that use case. AppArmor comes to mind, for example. > Alexandre also requested keeping games data separate so that it could be > moved out of the /usr partition because it could be quite large. This is > another concern that I think in the subsequent eight years has become a > bit less compelling due to the increase in the size of disks (which is > only sort of keeping up with full commercial games, but is certainly > keeping up with the games packaged in Debian). I don't know about you folks, but the last time *I* played a game on Debian, it was from steam, and all that crap ended up somewhere in my $HOME, nevermind the :i386 architecture mess I had to slap on as well. /usr/games certainly didn't help there... ;) So yeah, maybe we could gamesmerge? I can see the GR coming aaah! ;) a. -- The difference between a democracy and a dictatorship is that in a democracy you vote first and take orders later; in a dictatorship you don't have to waste your time voting. - Charles Bukowski
