On Tue, Jun 19, 2001 at 06:42:51PM -0500, Frederick Bruckman wrote:
> > INSTALL script looks to see if a scorefile is already present, and, if
> > not, creates it.

> The game doesn't create it when run? If not, then yes, you could do
> something like that.

The problem with just relying on the game is that, under the NetBSD
games permissions paradigm, games are setgid games, and not setuid.
If the game then creates the scorefile the first time it is run, it
will be created with the user who first runs it as the owner, which is
not how it should be.  (The mode will often be wrong, too, as the
user's umask will usually keep it from setting the group write bit.)
Thus the scorefile needs to be pre-created.

> > DEINSTALL script looks to see if the scorefile has changed from the
> > default (for many cases, the default would be zero-length, so this
> > would be easy, others might require some sort of .dist file on a
> > case-by-case basis), if not, deletes the scorefile, otherwise prints a
> > message indicating the user should delete it if it is no longer
> > needed.

> You can if you want to. IMHO, it's not that important. Lot's of games
> leave files in /var/games, and lots of other programs leave junk all
> over /var. That's what /var is for, isn't it?

IMHO, leaving these files all over is not good behavior, and packages
should, if possible, clean up after themselves as much as they
reasonably can, at least for files which they can determine are
unchanged from the install.  (You might have noticed that I included
_all_ leftover files in my bulk build results, not just /usr/pkg and
/usr/X11R6.  Doing the build in a chroot jail lets you do so without
worrying about e.g. log files from running programs interfering.)

I'm sure I'm not the only person who tends to do most of the builds on
a specific faster machine, and don't really want /var files left from
packages I won't ever run on that machine.  And there's always a
theoretical possibility, depending on the install process used within
the package, that having an older set of /var files might break the
install/package process of a newer version of the package - I've seen
similar problems with an old /etc/my.cnf, for example, breaking the
'make install' of a newer mysql-server...

At the very least, any packages which place files in /var (or /etc or
anywhere else, for that matter) should have that fact clearly
documented, including a listing of what specific files or directories
are there, and should present that list to the user upon deinstall so
the user is aware of what they can delete (if no longer needed).  Some
packages already do so, but far more should.

jdarrow

-- 
John Darrow - Senior Technical Specialist               Office: 630/752-5201
Computing Services, Wheaton College, Wheaton, IL 60187  Fax:    630/752-5968
Pager via email: 6303160707@alphapage.airtouch.com      Pager:  630/316-0707
Email:     John.P.Darrow@wheaton.edu