BSDGames/PACKAGING

Packaging bsd-games and bsd-games-non-free
==========================================

This file contains some information intended for those packaging
bsd-games or bsd-games-non-free for a Linux distribution.  It is
presumed that you have read INSTALL first, and that you have the
competence in the POSIX shell required to read and understand the
configure script.  This information may also be useful to people
building their own systems, who wish to rebuild the whole system
automatically or who use a packaging system for locally built
software.

The configuration and build of bsd-games has two features designed to
facilitate packaging:

1) Installation prefix.

The configure script allows you to choose an installation prefix (by
default empty) that is prepended to all paths used for installation,
but not those built into the executables (this is similar to the
install_root of glibc, and DESTDIR in some packages, but is chosen at
configure time).  The package would then be built in some way from
this directory, and the contents would end up in the root of the
target system.  If used, this prefix must be an absolute path.

2) config.params to change configuration defaults.

Although the configuration script is by default interactive (although
it does not need a terminal), it can also be used non-interactively.
If a file `config.params' exists in the source directory, it will be
sourced by the configure script.  If this file (which can be an
arbitrary shell script) sets `bsd_games_cfg_non_interactive' to `y',
then the default answers to all questions will be taken without
interaction.  If this sets `bsd_games_cfg_FOO' to `BAR' then the
default value for configuration parameter `FOO' will become `BAR'
instead of whatever default the script would otherwise give.  You can
find the names and meanings of the configuration parameters by reading
the configure script; they are not otherwise documented.

Issues for packagers
====================

Please read the security warnings in SECURITY.  There is a potential
trade-off between security and functionality present, and you may wish
to choose a potentially more secure default and allow the sysadmin to
change permissions if they are in an environment (for example, a home
system with only trusted users) where the functionality is preferred,
while ensuring such changes persist across upgrades.

You may wish to include auxiliary documentation for users, such as the
BSD Users' Supplementary Documents for trek and rogue
(trek/USD.doc/trek.me and rogue/USD.doc/rogue.me, or formatted
versions thereof), the AUTHORS and THANKS files, and the year 2000
statement YEAR2000.  Note that the trek manpage contains a reference
to /usr/doc/trek, which should be updated to point to where you put
trek.me or a formatted version.  As noted below, it is better to
update trek.6.in (before configure) than trek.6.

Assuming you distribute source for your package (I do not believe any
of the games have licences requiring this), and separate your patches
from the original source .tar.gz files (whether in separate files or
in a single file source package including them as separable
components), arranging the building of the source so that your patches
add a `config.params' as described above, and do any other necessary
changes to `configure' or other source files, and so that the build
process runs configure non-interactively and then builds the package,
makes it easier for readers to see how you have packaged it than
running configure interactively and including the generated files in
your patch.

Andries Brouwer has noted more than once on linux-kernel (and
elsewhere) that some packagers (for various software and documentation
used under Linux):

(a) Do not send their patches to upstream maintainers, so that
improvements and bug fixes stay in some distributions, which may need
to discover them independently, and do not come to benefit other
users.

(b) Keep applying their same patches to new versions of the source as
long as they apply without error, even though they may no longer be
needed or even be harmful.

If you have patches that are needed for the package to build (in a
supported environment: libc 5.3.12 (or any Linux libc before 5.4.5)
and glibc 1.99 (or other old snapshots) are not supported although the
latter may work; nor is BSD curses/libtermcap or ncurses before 1.9.9e
(== 3.0 shared library version)) or to fix bugs (again in a supported
environment) or that provide enhancements other than conforming to
distribution-specific policy, please send them to me (unidiffs
preferred; see notes on bug reporting and sending patches at the end
of README).  Do not assume that old patches should be applied to new
versions; check that the problem they are supposed to fix is still
present first.

Warnings
========

If distributing bsd-games, it is your responsibility to check that the
licences on the games you distribute permit what you wish to do with
them, and that you are providing accurate information on the licences
to your users.  Likewise it is your responsibility to carry out
whatever audits you deem necessary on the code, and to include such
warnings or information (about security and otherwise) for the end
user as you see fit.  Please read the disclaimers in the individual
source files.

Some of the games may contain material, actions or language that in
some jurisdictions may be prohibited or considered unsuitable for
minors; this includes but is not limited to the offensive fortunes.
It is your responsibility to determine and apply any restriction on
your distribution of the games that may be necessary in consequence.

Notification of new versions
============================

If you want to receive notification of new versions by email, but do
not currently receive this notification, please let me know.

A note on terminology and credit
================================

I am not the `upstream author' of the games packaged here; for an
incomplete list of the authors see AUTHORS, but do not give me this
credit I do not deserve at the expense of the true authors.  Rather I
am the `upstream maintainer' of the bsd-games and bsd-games-non-free
packages (upstream relative to distributions), and upstream of me is
NetBSD, who also are maintainers of the games, but not for the most
part authors.  Nor am I the creator of the bsd-games package, although
much the current form of the packaging and many of the porting changes
are mine: the package was created by Curt Olson and Andy Tefft, and
passed to me after it had been idle and unmaintained for some years.
Any system that provides fields for recording this sort of information
should distinguish these concepts, and the different fields should be
filled in correctly.  Please consider where credit is due and credit
the authors of the games accordingly: if you find the names of authors
where not known and listed in AUTHORS, or up-to-date contact details
for authors listed there, please send me the details so they can
receive their due credit in future versions, and thanks from any
appreciative users.