[fhs-discuss] games/ as a separate directory

Karl Goetz karl at kgoetz.id.au
Thu May 5 17:57:08 PDT 2011


On Thu, 05 May 2011 12:39:05 -0400
Jeff Licquia <licquia at linuxfoundation.org> wrote:

> On 05/05/2011 04:27 AM, Richard Hartmann wrote:
> > 1) How is this to be interpreted?
> >
> >> The following directories, or symbolic links to directories, must
> >> be in /usr/ share, if the corresponding subsystem is installed:
> > [...]
> >> games     Static data files for /usr/games (optional)
> >
> > Possible interpretations include
> >
> > a) "/usr/games is optional when games are installed"
> > b) "/usr/games must be created if there are any games installed"
> > c) "/usr/games must be created _and used_ if there are any games
> > installed"
> >
> > In any case, the wording of this section should probably be
> > improved.
> 
> I agree; there's some ambiguity here.  Oddly, /usr/games is not 
> referenced anywhere else in the current spec.  I don't think it's
> wrong to install games to /usr/bin (and the specification definitely
> does not forbid it), so maybe we want to just drop references
> to /usr/games, or deprecate it.

Rereading the spec i realised it says 'or symbolic links'. this means
a /usr/games -> /usr/bin symlink would bring anyone putting games
in /usr/bin into compliance. 

> The mentions of /usr/share/games and /usr/lib/games seem a bit like 
> micro-management to me.  Certainly, they should not be disallowed,
> but what's wrong with /usr/share/[mygame]
> vs. /usr/share/games/[mygame]?

I expect its to keep all the games stuff in special games directories.
binaries, data, state, etc are all under /*/games/. This allows
excluding */games/ from your backups and they're all gone.
Seems 1.6TB backup tapes (LTO4) can be picked up for < $100 atm, so
this need is probably less then it was when these directories started
being used. (the cost may not be relevant at all, considering none of
the big games are likely to be on machines being backed up in that way).

> I think I'd want to expand the comment about writeable game data to
> be true across the board, not just for games.  Writeable stuff should
> go in /var, and non-writeable data should go in /usr/share
> (or /usr/lib if it's arch-specific).

I agree with this.

> > 2) Is this section going to change? Some people within Debian don't
> > see the use of maintaining this separation (any more). While this
> > rationale makes sense:
> >
> >>      Rationale: /var/games has been given a hierarchy of its own,
> >> rather than leaving it merged in with the old /var/lib as in
> >> release 1.2. The separation allows local control of backup
> >> strategies, permissions, and disk usage, as well as allowing
> >> inter-host sharing and reducing clutter in /var/ lib.
> >> Additionally, /var/games is the path traditionally used by BSD.

[trim]

> Yes, I agree that we should probably look at the list of
> subdirectories in /var in general.  The case for /var/games is
> stronger, though, as mentioned in the mailing list post you linked;
> the convention of setting up score files and the like there, along
> with some security via setgid games or some such, is well established.
> 
> But if there are folks who'd like to get rid of /var/games, send them
> on to us; we'd love to hear their rationale.

If /usr/share/games and /var/games go I see no reason to keep
/usr/games. I think we should ditch the */games sub-directories for all
of them. If we keep /var/games for its job of keeping scores i'm
wondering if there is a better place we can put it under (I'm seeing
why we might want it to stay around, just seems like an odd
inconsistency).
thanks,
kk

-- 
Karl Goetz, (Kamping_Kaiser / VK5FOSS)
Debian contributor / gNewSense Maintainer
http://www.kgoetz.id.au
No, I won't join your social networking group
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/fhs-discuss/attachments/20110506/7d1cd68f/attachment.pgp 


More information about the fhs-discuss mailing list