There is a need for Battle for Wesnoth to be packaged into formats convenient for people to use on different platforms. This is not only because not everyone has a compiler, but also because not everyone has the *time* to spend configuring and compiling each new release of Battle for Wesnoth.
Therefore, it behooves us to assist our fellow BfW players and, if we are able, to provide standardised, well behaved install packages for the various platforms that we use.
Speaking generally; wherever possible, Battle for Wesnoth should be built as closely according to CompilingWesnoth as possible. This means using the default file locations, not relocating the package to custom filesystems or directory layouts (unless required for the platform conformance), and generally being as absolutely conservative and predictable as possible in the build of the package. Amongst other things, this will greatly ease troubleshooting if problems are encountered; both for yourself, and the end user of your package.
Below are general guidelines and tips for creating BfW packages on a variety of platforms.
GNU/Linux RPM-based systems
These include RedHat, Fedora Core, Mandrake, SuSE, and others. Many popular Linux distributions use RPM for their package management system.
RPM relies upon a .spec file (see http://www.rpm.org/RPM-HOWTO/) to describe the actions taken to compile and install the Wesnoth binaries. This .spec file is broken down roughly into an area of meta-data (program name, version, vendor, etc), an area dealing with the steps required for compilation, and an area dealing with how do grab the resulting files and place them on the host filesystem. An in-depth discussion of RPM creation can be found at http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowTo.
Sample wesnoth.spec files can be found at: http://pythonhacker.is-a-geek.net/main/downloads/my_packages/bfw. These can be used as a starting point for building Battle for Wesnoth RPMs on almost any RPM based system.
RPM files are monolithic; in that they are designed to only contain a complete program, rather than parts of a program. This means that when you package Battle for Wesnoth with RPM, you will be duplicating a lot of files that are otherwise unchanged from one version to the next. This means more time downloading for your end users, and higher bandwidth costs for yourself. One solution for this is to use RUKS, the RPM Upgrade Kludging System (http://pythonhacker.is-a-geek.net/main/downloads/my_programs/ruks). This allows to to use RPM to create a 'difference patch' to move between two versions of a program with RPM. For example, traditionally with RPM, to upgrade from 0.1 to 0.2 of program X, one packages a full copy of version 0.2 into an RPM package, and then the end user installs it and in the process wipes all of version 0.1. RUKS allows you as the packager to create an RPM package that only contains changed and new files from version 0.1 to 0.2. Your end user then installs the 0.2 package alongside their existing 0.1 installation.
RPM packages should comply as closely as possible with a standard Wesnoth install. After the install of the RPM file there should be little or no difference from the end user's perspective to what they would have got with a ./configure, make, make install
GNU/Linux Debian-based systems
GNU/Linux Slackware-based systems
MacOS X systems