Initial revision

git-svn-id: file:///srv/svn/joey/bsdgames-trunk@5086 a4a2c43b-8ac3-0310-8836-e0e880c912e2

PACKAGING

@@ -0,0 +1,140 @@
+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.