Re: [AD] Data file directory

[Tim Bird <tbird@xxxxxxxxxx>]

Shawn Hargreaves wrote:
> 
 - Games are ephemeral. Rather than a handful of standard programs that
are
> required to be available, most people install many of them at regular
> intervals, play them for a while, then get bored and want to reclaim that
> space. For this, it strikes me as quite important for the game to be
> self-contained so that it can easily be deleted when you want to do that.
All modern Linux systems include package managers which track file
locations, library dependencies, and other items, for each of the
packages
on the system.  It is trivial to eliminate a packaged application from
a Linux system.  The two most popular forms of packages are debian
packages
and RPMS.  It is not entirely the case now that all programs for Linux
come in packaged form, but most do.


Actually
> 
> So I think there is quite a strong case for Unix games that install into a
> subtree of your home directory (that's where I tend to put things while I'm
> playing around with them, and with a game, I delete it after that first
> period of playing around, rather than moving it to some more permenant
> location), or perhaps into a subtree of /usr/local/games (note that in a
> completely stock Red Hat 6.0 installation, /usr/games/fortune is not in the
> default path).
Requiring users to install things under their own directories is pretty
bad.  Allowing it is OK.  Even in a system used by only one user, it is
not
uncommon for multiple accounts to be used (even if it's only root and a
single
user account), and it's worthwhile to put a game where it can be
accessed
by more than one account.  It would be best (IMHO) if games based on
Allegro
were packaged and followed the FHS or LSB standards for file placement
in
Linux.  Obviously, many games will go out as tarballs, and the usual
practice
there is to use /usr/local/<prog_name>/... and either put symlinks or
shell script wrappers in /usr/local/bin.

> 
> This is really up to the individual author, though, since everyone is liable
> to have different ideas.
True.  What I put above is just my 2 cents.
> 
> > I thought it might be good to add a function to return a directory for
> > reading data files and possibly a different one for reading writable files
> > (subject to permissions still, of course).
> 
> I certainly don't mind that if people think it would be useful, but I doubt
> I would use it myself. I can't help feeling that this is a slightly odd
> thing to abstract, since it is trivial to do this yourself on Unix, while
> the problem simply doesn't arise on DOS or Windows. This means that the API
> function would essentially end up as a series of "return standard Unix
> directory name" calls, which would all just be defined to the program
> directory on other platforms: not perhaps a bad thing, but kind of pointless
> since it would just be another layer of code for people to learn, and to use
> this properly you would have to understand the difference between readonly
> data, per-user configs, etc, and if you understood that you might as well
> just use getenv("HOME"), "/var", etc, directly. It seems like a Unix person
> would not need these functions to be in Allegro at all, while a non Unix
> person wouldn't understand what they were or how/why to use them...
I tend to agree with this assessment.  I think what George was looking
for
was something that would abstract to the developer the path handling, so
they
wouldn't have to have special case code to deal with the platform.  But
this
requires that everyone learn a new abstraction.  Not necessarily bad,
but
I think it's unlikely to be used.

____________________________________________________________
Tim Bird                                  Lineo, Inc.
Chief Technology Officer                  383 South 520 West
tbird@xxxxxxxxxx                           Lindon, UT 84042