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.