Bug#567033: Decide if we should continue recommending /usr/games

On Mon, Sep 11, 2023 at 07:11:30PM +0100, Simon McVittie wrote: > 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

Bug#567033: Decide if we should continue recommending /usr/games

Hi, The bespoken machine of 2015 with 64GB of SSD has been repurposed as a Buster (the "new" os at work) backporter box, but I'm still here. I agree that the games in Debian - especially the free ones - don't evolve that much, don't grow so much, but on the "contrib engine + non-free assets"

Bug#567033: Decide if we should continue recommending /usr/games

Antoine Beaupré writes: > On 2023-09-11 11:25:34, Russ Allbery wrote: >> Antoine Beaupré writes: >>> I get the argument against bad binaries not being in PATH but we have >>> some tooling for that, don't we? /usr/libexec, no? >> /usr/libexec isn't a replacement because it's not on any user's

Bug#567033: Decide if we should continue recommending /usr/games

On Mon, Sep 11, 2023 at 02:38:14PM -0400, Antoine Beaupré wrote: > On 2023-09-11 11:25:34, Russ Allbery wrote: > > Antoine Beaupré writes: > > > >> I get the argument against bad binaries not being in PATH but we have > >> some tooling for that, don't we? /usr/libexec, no? > > > > /usr/libexec

Bug#567033: Decide if we should continue recommending /usr/games

On 2023-09-11 11:25:34, Russ Allbery wrote: > Antoine Beaupré writes: > >> I get the argument against bad binaries not being in PATH but we have >> some tooling for that, don't we? /usr/libexec, no? > > /usr/libexec isn't a replacement because it's not on any user's PATH. > /usr/games is intended

Bug#567033: Decide if we should continue recommending /usr/games

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

Bug#567033: Decide if we should continue recommending /usr/games

Antoine Beaupré writes: > I get the argument against bad binaries not being in PATH but we have > some tooling for that, don't we? /usr/libexec, no? /usr/libexec isn't a replacement because it's not on any user's PATH. /usr/games is intended to be added to a regular user's path but not root's,

Bug#567033: Decide if we should continue recommending /usr/games

On 2023-09-11 19:11:30, Simon McVittie wrote: [...] > 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

Bug#567033: Decide if we should continue recommending /usr/games

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

Bug#567033: Decide if we should continue recommending /usr/games

On Mon, Sep 11, 2023 at 12:51:33PM -0400, Antoine Beaupré wrote: > On 2018-06-14 11:42:22, Simon McVittie wrote: > > Debian can choose to put games in the /.../games directories, or in the > > standard directories /usr/bin, /usr/share etc., or any mixture of our > > choice, orthogonal to

Bug#567033: Decide if we should continue recommending /usr/games

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

Bug#567033: Decide if we should continue recommending /usr/games

Antoine Beaupré writes: > I wonder if we should just do the same. I'm not sure I see the point of > having all that stuff in a separate directory, personnally, but at least > in this case we shouldn't needlessly diverge from upstream... although > in terms of upstream for bsd-games, things are

Bug#567033: Decide if we should continue recommending /usr/games

On 2018-06-14 11:42:22, Simon McVittie wrote: > Debian can choose to put games in the /.../games directories, or in the > standard directories /usr/bin, /usr/share etc., or any mixture of our > choice, orthogonal to whether/when we move to FHS 3.0. It's been a while since this was discussed, but

Bug#567033: Decide if we should continue recommending /usr/games

Control: unmerge 567033 On Fri, 11 Aug 2017 at 07:07:49 -0700, Sean Whitton wrote: > The latest version of the FHS does not have /usr/games, so merging this > with the bug about updating our FHS version. Removing the games directories was considered in

Bug#567033: Decide if we should continue recommending /usr/games

On Fri, 11 Aug 2017 16:31:09 +0200 Axel Beckert wrote: > Sean Whitton wrote: > > The latest version of the FHS does not have /usr/games, so merging this > > with the bug about updating our FHS version. > > Meh. > > From my point of view we should continue to keep /usr/games/

Bug#787816: Bug#567033: Decide if we should continue recommending /usr/games

Hi, Sean Whitton wrote: > The latest version of the FHS does not have /usr/games, so merging this > with the bug about updating our FHS version. Meh. >From my point of view we should continue to keep /usr/games/ for games as that helps to distinguish games from tools with the same name — which