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
The configuration and build of bsd-games has two features designed to
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. Some packagers
may wish to provide a security-hardened system by giving each setgid
game its own group so bugs in one do not affect others.
You may wish to include auxiliary documentation for users, such as the
AUTHORS and THANKS files and the year 2000 statement YEAR2000.
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
Since bsd-games no longer comes with its own words file, you may wish
to ensure that the same dictionaries are used in the build of boggle
regardless of the local configuration of the dictionaries installed on
the computer used for the build. (The list used by hangman can also
be specified by the user at run time; future versions may provide for
this to be done with boggle as well; see TODO.)
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
(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 or to fix
bugs (in a supported environment, not with old versions of libraries
and tools) 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
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
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.
This package contains cryptographic software (caesar and rot13). See
the warnings in README about this.
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