INTRODUCTION Long before the existence of "slackbuilds.org", "linuxpackages.net" and similar semi-official sites offering Slackware package building scripts, the need arose to augment the official package offerings from Slackware.com. Over the years, the capability of this package building library eclipsed what was offered in public "slackbuilds"; though numerically insignificant compared with "slackbuilds.org" today, this enhanced capability warrants the continued use of Moonlit Rail's system. The Moonlit Rail slackbuild system consists of one file shared by each of the individual package building scripts called "LIBRARY", and then (in most cases) a single shell-script file that builds the package in question. All of the complexities of locating source and package version numbers, un-tarring, configuring, building, installing and packaging are handled by functions defined within the LIBRARY file; as a result, the individual package building scripts tend to be very compact and easy to read. COMPARISON WITH (SEMI)OFFICIAL SLACKBUILD SCRIPTS 1. Easy to write In the majority of cases, a Moonlit Rail slackbuild script consists of just a few simple commands within a shell script file: . /path/to/mr-slackbuilds/LIBRARY Loads the main library initialize Untars source, etc doconfig -s feature feature !badfeature Smart configuration sbmake -j; sbinstall Build & install fixman; fixinfo; stripbin; copydocs docs/ Post-install fix-up echo "My Description Here" | slackdesc Documentation slackend Package it up The Moonlit Rail slackbuild "LIBRARY" file contains many well-featured callable functions that do all the "heavy lifting" involved in each stage of package creation. The examples above are common, but are only a small sample of what the library offers. 2. Compact The (semi)official slackbuild scripts are monolithic; they do not utilize functions stored within included library files. Moonlit Rail's versions do utilitize a library file and thus are tight and compact, with most of the size consumed by textual elements such as the package description. The (semi)official slackbuilds also require a minimum of two files in addition to the software source: the "packagename.SlackBuild" shell script, and the "slack-desc" package description. Moonlit Rail's scripting combines all the information needed to build a package into one file - its slackbuild shell script. 3. Multiple versions handled with one script The (semi)official slackbuilds are typically "hard-wired" to a single software source version. If you replace the software "tarball" with a newer version, for example, the slackbuild script will not work without modification. Worse still, many of these slackbuilds are packaged along with patch files which will also (in many cases) need to be altered to work with the newer source. The Moonlit Rail slackbuilds dynamically adjust to different software versions (at least for minor version differences, and sometimes for major ones as well). They also dynamically modify source files as necessary, rather than relying upon "patch" files tied to specific version numbers. 4. Conscious of existing packages A Moonlit Rail slackbuild will not build a binary package if an up-to-date one already exists in the destination directory. (But you can always force it to do so, if you like.) If a newer binary package is to be built to supersede an existing one with the same version number, the build number will automatically be incremented. 5. Does not throw away useful debugging symbols Slackware sadly throws away most debugging symbols from its libraries, making back-traces nearly useless. Although you can ask the Moonlit Rail slackbuild to do likewise, by default it will keep debugging symbols. HOW TO USE THE MOONLIT RAIL SLACKBUILD SCRIPTS Each of the package-building scripts offered in Moonlit Rail's slackbuild system are executable shell scripts. By default, they (along with the companion LIBRARY file) live in the directory /usr/local/lib/slackbuild/ which you are encouraged to peruse. If you execute any of these scripts giving it the canonical UNIX "-h" help flag, it will print out the list of flags and options the script supports. Absent any options provided by you, the script will look in the current directory for a source tarball, look for a companion and up-to-date Slackware package with the same version number, and if not found, will build a package from source. If more than one source version exists in the source directory, the scripts will utilize the one with the numerically highest version number. For example, download the newly-released source for the University of Washington's IMAP server, imap-2007f.tar.gz, and put it into your current directory. Then, as root (because the script needs to set root permissions on system files) you execute the Moonlit Rail slackbuild script like this: ~# /usr/local/lib/slackbuild/imap Will build a new Slackware package for imap 2007f Patching OSDEP Makefile ... OK Building static library ... OK IMapd internal version number is 2007f.404 Building shared objects ... OK Linking dynamic library ... OK Patching imapd Makefile for dynamic library linking... Making imapd ... OK Installing ... OK Copying docs... OK Changing mode of /usr/doc/imap-2007f/draft from 2755 to 755 Changing mode of /usr/doc/imap-2007f/rfc from 2755 to 755 Packaging... OK Done Package imap-2007f-i686-1 is ready for installation. ~# ABOUT THE AUTHOR AND LICENSE The Moonlit Rail slackbuild scripts were written by and are Copyright © 2011 Kristofer T. Karas, all rights reserved. Please see the GNU General Public License in the file COPYING for licensing information. You might also wish to have a look at the file called CATALOG (which should be located where this README and the COPYING file are) which briefly lists why each Moonlit Rail slackbuild exists. FREQUENTLY ASKED QUESTIONS - FAQ Q: You have slackbuilds for packages already in Slackware. Why? A: Many of the packages created by Moonlit Rail's slackbuilds have different features enabled from those offered by the official Slackware repository. Patrick Volkerding, who creates Slackware, tends not to like to include packages that have different licensing arrangements from the usual GPL. For example, both OpenSSH and SAMBA can take advantage of MIT Kerberos to allow single sign-on as well as authentication against popular agents such as Microsoft's Active Directory. But because Kerberos is distributed with a MIT license, it is omitted from Slackware. Moonlit Rail's slackbuilds not only build packages for Kerberos, but likewise for those systems that can use it. In some cases, the software versions employed by Slackware are curiously obsolete, made more striking when dealing with slackware-current. Some nagging by the author inspired Patrick Volkerding to upgrade OpenLDAP from 2.3 to 2.4; but the current version of MySQL is still behind at 5.1. Q: Will I break compatibility with Slackware if I use these instead? A: The only incompatibilities known to exist are linkages against MySQL. Several Slackware packages that use the QT graphical toolkit use its SQL driver /usr/lib{64}/qt/plugins/sqldrivers/libqsqlmysql.so which will need to be recompiled if you use Moonlit Rail's slackbuilds to update your MySQL installation. Similarly, you may need to re-build your DBD::Mysql module if you use any database-driving perl scripts. ------------------------------------------------------------------------------ Local Variables: mode: text fill-column: 78 coding: utf-8 End: