Slackware’s “magic package maker”

Slackware Linux today features a powerful and easy-to-use package management system, but making Slackware packages has not always been straightforward. Now Slackware application developers have a tool for easily making Slackware packages from source code and precompiled binaries. Src2pkg, now in version 1.6, very nearly lives up to its author’s tag of being Slackware’s “magic package maker.”

The traditional method for installing software in Linux is to download the source code, uncompress it, and then run ./configure && make && make install. The result is compiled software that is installed in the (hopefully) correct spots in the file system. The problem is that there is no easy way to track which files end up at which locations. The result is that it can be extremely difficult to remove or upgrade applications.

Package managers solve that problem. Slackware packages are simply tar archives, compressed with gzip (with the .tgz extension), that contain a file structure and the compiled files. Slackware’s package tools unpack the package files to the correct directories and maintain a database tracking where the files are installed.

Many people seem to equate package management with dependency checking. In fact, dependency checking is a secondary and, from a Slackware perspective, a largely unnecessary part of package management. A full Slackware installation includes a reasonably complete set of libraries so that the dependancies for most software are already included. However, when other libraries are required, the application’s Web page usually lists them so they can be downloaded, compiled, and installed. In just over a year of using Slackware, I have had to install fewer than 10 libraries for the applications I built.

Until recently the two best ways to make Slackware packages were to use the program Checkinstall or use SlackBuild scripts. Both methods compile source code, create a directory structure, and package everything in a .tgz file. Checkisntall works by substituting the checkinstall command for the make install command. Checkinstall works well with Slackware 11 (released October 2006), but an incompatibility with the latest coreutils causes problems for Checkinstall with Slackware 12 (released July 2007).

SlackBuilds are bash shell scripts that guide the configuration, compilation, and packaging of source code. Well-written SlackBuilds work extremely well. Slackbuilds.org maintains a high-quality community repository of SlackBuild scripts for a wide varitey of software.

Src2pkg, a better alternative

Src2pkg, a command-line utility for which version 1.0 was released in February, offers a superior alternative to Checkinstall, and is useful a SlackBuild script is not readily available for an application or a user is not experienced enough with shell scripting to make one. Src2pkg’s author, Gilbert Ashley, designed the program to not only compile Slackware packages from source code, but also from Debian or RPM package binary files, and from generic binary files, which are described in the src2pkg manual as “binary content which is usually installed by running an install.sh script, .run file, or other installation routine.” Finally, src2pkg will create build scripts so that users can customize their package builds. Providing a number of options for dealing with source code is necessary because of the wide variety of ways that source code is distributed.

Version 1.6 of src2pkg was officially released on September 18. I downloaded its Slackware package from from the author’s Web site and installed it. I built and installed four packages to test the various features of src2pkg, its documentation, and the level of support offered by its author.

The easiest way to use src2pkg is to log in as root and simply type src2pkg filename, but the man page list a number of switches to customize the build process. User options use capital letters following a dash, and build options use lowercase letters following a dash. I found the following user options useful for my builds:

• -C — place finished package in the current directory
• -N — generate a starting src2pkg script and slack-desc description file without building the package
• -S — use a shell script for installation (install.sh by default)
• -VV — be verbose — show all output from the build steps
• -W — remove (wipe out) temporary build files
• -X — run the first src2pkg or src2pkg.auto script in the current directory

In addition to the man page, src2pkg has documentation available in the /usr/doc/src2pkg-1.6 directory. The additional documentation consists of HTML-encoded descriptions of the various features and functions of the application, two README files, and an FAQ text file. The documentation is informative and helpful. The information is dense but well-written and contains many helpful suggestions for building packages.

Building Slackware packages

I built Emacs 22.1 as my first package. This latest version of Emacs was released a month or so before the latest version of Slackware, but there is to date no official Slackware package for it and no SlackBuild script available at Slackbuilds.org. I took advantage of another feature of src2pkg and used it to download the source file and then build the package with this command:

src2pkg http://ftp.gnu.org/pub/gnu/emacs/emacs-22.1.tar.gz

Src2pkg successfully downloaded the source code archive, and configured, made, and built the package. The configure process automatically found the GTK libraries. When src2pkg finished, it displayed a message with the location of the Slackware package. I installed it, and Emacs 22.1 ran without a problem. In fact, all of the packages I built with src2pkg installed successfully and ran well.

I experienced a problem when I attempted my next built of the desktop publishing program Scribus 1.3.3.9. My first attempt resulted in an error:

Creating working directories:
   PKG_DIR=/tmp/scribus-1.3.3.9-pkg-1
   SRC_DIR=/tmp/scribus-1.3.3.9-src-1
Unpacking source archive - Done
Decompressing (unknown) archive: Scribus.app.tgz FAILED!
Unable to unpack Scribus.app.tgz. Exiting...
src2pkg FAILURE in UNPACK_RENAME

A quick email message to Gilbert Ashley produced a response with the solution. The error was the result of “a very rare snag with tarballs that contain another (or more) tarballs inside them.” The fix is to open the file /usr/libexec/src2pkg/FUNCTIONS and uncomment line 778 from #OPEN_SOURCE=1 to OPEN_SOURCE=1. That line is in the file, but commented because the author is aware of the glitch.

After making that configuration change, the Scribus package built correctly. The command I used to build Scribus used options to ensure that I could see the output of the build process, that the finished package was placed in the directory with the source code, and that the temporary build files were deleted after the package was built:

src2pkg -VV -C -W scribus-1.3.3.9.tar.bz2

To test src2pgk’s ability to convert RPM files and its creation of build scripts, I downloaded a game called Orbit, file name orbital-1.01-691.i586.rpm, from the OpenSUSE 10.2 repository. The command src2pkg orbital-1.01-691.i586.rpm -N built a src2pkg script called orbital.src2pkg.auto. The command src2pkg -VV -C -W -X built the package using the src2pkg script in that directory.

The build script generated by src2pkg is very simple, consisting of 44 lines. The following lines are where some users will want to add configuration options:

# Any extra options go here
# EXTRA_CONFIGS=''
# STD_FLAGS='-O2 -march=i486 -mtune=i686'

Build scripts can help users save specific configuration options so that they can be repeated each time the package is built. Additionally, build scripts can be real time-savers when you’re troubleshooting a package build. Simply change a line or two in the script, build the package again, and repeat the process until the package is just the way you want it.

My final package build for this test was Opera 9.24. Opera distributes the browser’s source code as a generic binary that uses an interactive shell script, install,sh, to configure and build the application. Therefore, src2pkg requires the use of the -S switch.

To build the package, I used the command src2pkg -C -VV -W -S opera-9.24-20071015.6-shared-qt.i386-en.tar.gz. The interactive installation script successfully ran within the src2pgk process.

Recommendation

I unreservedly recommend src2pkg for Slackware users. The program enabled me to quickly build Slackware packages that installed and ran without problems. More importantly, src2pkg made it easy to change options and experiment with my builds. I actually built each package a few times to test the different features of scr2pkg. Glibert Ashley is active on the Slackware forum at Linuxquestions.org and is quick to answer questions about src2pkg. His level of product support is outstanding.

The one area where src2pkg could use some improvement is with the documentation. As with any command-line utility, it is essential to read the manual to lean how to use the application. Src2pkg’s documentation is well-written and informative, but also distributed over too many files. I would like to see everything available as a man page or an info file with nodes. Additionally, it would be nice to have a list of possible errors and some suggestions on how to address them.

However, the best way to learn any program is to use it frequently and experiment. Src2pkg makes it easy to do both.