This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Slackware

Slackware's "magic package maker"

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

Share    Print    Comments   

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.

Drew Ames is a transportation planner in Harrisburg, Penn.

Share    Print    Comments   

Comments

on Slackware's "magic package maker"

Note: Comments are owned by the poster. We are not responsible for their content.

Slackware's "magic package maker"

Posted by: Anonymous [ip: 62.99.208.50] on November 30, 2007 10:41 AM
I am using something similar, but much easier and simpler:
http://slackware.php.co.ba/src2slack

#

Re: Slackware's "magic package maker"

Posted by: Anonymous [ip: 87.68.193.212] on February 08, 2008 02:08 PM
Consider using the http://portpkg.berlios.de This is a ports system for Slackware - good piece of soft. The project provides the 'autoport' utility that is able to build SlackBuild from source URL. The project also integrates package and build script repositories (linuxpackages.net, slacky.eu, slackware.com, slackbuilds.org ...) to manage them from one place

#

Slackware's "magic package maker"

Posted by: Anonymous [ip: 216.109.50.126] on November 30, 2007 04:48 PM
Apparently the author of src2slack doesn't understand the concept of copyright.

set_arch_vars() {
# this code is from alien's slackbuilds:
# http://www.slackware.com/~alien/


The code appears to be a verbatim copy.

#

Apparently you don't understand the concept of "Free Software"

Posted by: Anonymous [ip: 67.90.11.226] on November 30, 2007 06:24 PM
Assuming "alien's slackbuilds" is under the GPL, which seems highly probable, it is OK to copy code verbatim into another GPL program. If the licenses involved are other free licenses, it may or may not be OK.

#

Re: Apparently YOU don't understand the concept of "Free Software"

Posted by: Anonymous [ip: 216.109.50.126] on November 30, 2007 06:48 PM
No, you don't understand. It's not the copying that's the problem.
However, copying the code without including the copyright notice (which is part of the conditions of redistributing the copied code) is a problem. It's a serious problem.
Do yourself a favor and try to understand the big picture before you start commenting.

#

Re(1): Apparently YOU don't understand the concept of "Free Software"

Posted by: Anonymous [ip: 62.178.15.139] on December 01, 2007 06:25 PM
You are absolutely right and I sent an email to the author of src2slack. He answered me a few minutes ago:

quote
Thanks for your email.I forgot to put the copyright notice. The comment was there just for me, and I forgot to change it before uploading it.
/quote

It is changed now as I can see:
# http://www.slackware.com/~alien/
# Copyright (c) 2007 Eric Hameleers <alien@slackware.com>
# All rights reserved.

I like this script, it is pretty cool. And it uploads packages to my server per ftp. I will contact author and ask him to also insert "scp".

#

Slackware's &quot;magic package maker&quot;

Posted by: Anonymous [ip: 24.59.156.195] on November 30, 2007 06:26 PM
Yay! Another Linux package manager! We don't have enough of those. How about a few dozen more so that in a couple years, we'll have to install two dozen packages just to install.. um, a package manager.

#

Another moron

Posted by: Anonymous [ip: 216.109.50.126] on November 30, 2007 06:49 PM
Except it's not a package manager. It's a package creator.
Try reading the article before commenting next time.

#

Re: Slackware's &quot;magic package maker&quot;

Posted by: Anonymous [ip: 207.102.78.125] on November 30, 2007 07:14 PM
um, it's a package builder, not a package manager. did you read the article?

#

Re: Slackware's &quot;magic package maker&quot;

Posted by: Anonymous [ip: 211.30.163.5] on December 01, 2007 10:52 AM
Its near Christmas time...The Morons are out early this year!

#

Slackbuilds like Arch pkgbuilds?

Posted by: Anonymous [ip: 169.233.25.231] on November 30, 2007 08:06 PM
For the Arch inclined, could someone explain if slackbuilds are like Arch's pkgbuilds?
Thanks.

#

Re: Slackbuilds like Arch pkgbuilds?

Posted by: Anonymous [ip: 211.30.163.5] on December 01, 2007 10:53 AM
Same fundamental concept as ABS in Arch Linux, but slightly different in features.

#

Re: Slackbuilds like Arch pkgbuilds?

Posted by: Anonymous [ip: 87.68.193.212] on February 08, 2008 02:05 PM
Not exactly. SlackBuild is an independent shell script and needs no other tool (but sh) to build a package.
And the pkgbuild is a description of how to build but needs the builder application installed

#

Slackware's &quot;magic package maker&quot;

Posted by: Anonymous [ip: 75.39.130.100] on November 30, 2007 08:13 PM
Although Emacs was mentioned, this is a great write up about a terrific bit of coding. And, I completely agree about the point of dependency checking.

#

Re: Slackware's &quot;magic package maker&quot;

Posted by: Anonymous [ip: 69.227.163.88] on December 03, 2007 05:08 AM
What do you mean although Emacs was mentioned? This was a great article made even better by the presence of Emacs.

Emacs > Vi, Emacs FTW!

#

GNU stow

Posted by: Anonymous [ip: 10.100.209.150] on December 04, 2007 07:06 AM
There's always been stow.

I compile all my software to /opt/<name-and-version-of-program> and use
stow to make links to /usr/local. Easy to delete, easy to copy to another computer, easy to
try different versions of the same program.



- Peder

#

Slackware's &quot;magic package maker&quot;

Posted by: Anonymous [ip: 149.32.192.33] on December 17, 2007 06:53 PM
I'm really quite excited with src2pkg. I've had a hell of a time using checkinstall on Slack 12. I think this is definitely a very good addition to the slack utilities. Compliments pkgtool very nicely.

#

Slackware's magic package maker

Posted by: Anonymous [ip: 87.68.193.212] on February 08, 2008 01:57 PM
Consider using the http://portpkg.berlios.de This is a ports system for Slackware - good piece of soft. The project provides the 'autoport' utility that is able to build SlackBuild from source URL. The project also integrates package repositories (linuxpackages.net, slacky.eu, slackware.com and others) to manage them from one place

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya