Saturday, February 23, 2008

Slackware/Zenwalk: src2pkg tool

from: http://www.linux.com/feature/121499

Slackware's "magic package maker"



By Drew Ames
on
November 30, 2007 (9:00:00 AM)

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.



No comments: