System administration



autopkg - create Slackware packages from source


autopkg gimp-1.2.1.tar.gz
autopkg -n wmaker WindowMaker-0.62.1.tar.gz
autopkg directory


autopkg makes Slackware packages from source. A rules file in the form name.apkg must be created first; then binary packages may be created. The rules file should be made to work with the original source distribution.

Either the source archive or directory may be given on the command line. The software's name will be determined, and the corresponding rules file, ~/.autopkg/name.apkg, will be used to build the package.

For example, with the following invocation:

    autopkg gimp-1.0.4.tar.gz

the name ``gimp'' will be extracted first, then autopkg will look for ~/.autopkg/gimp.apkg. Finding that, it will extract the tarball to a temporary directory, and follow the rules to build the package.

Rules files are perl scripts that are eval'd when identified. They define functions which are called at strategic points during the packaging process, and may modify some global variables to change the main program's behavior with regard to file permissions and ownership.


-b, --build num
Set the build number, which can be included in the package filename.
-c, --combine name package.tgz package.tgz [package.tgz ...]
Combine several packages into one. This option provides an operation that is distinct from normal package building, and when it is used, the -n and -r options will be ignored. The install/ scripts will be concatenated in the final package. No other filename collision avoidance will be attempted.
-d, --destdir dir
Specify the directory to which the package should be written. Overrides $OPTIONS{DESTDIR}.
-h, --help
Print a short usage summary.
-i, --id id
Provide the packager's id. Generally the initials of the person using autopkg. This value is stored in $ID, and used to generate the package filename.
-n, --name name
Sets the value of $NAME to name. Also causes the rules file ~/.autopkg/name.apkg to be used, unless the -r option is used.
-r, --rules rules-file
Use the arbitrarily-located rules-file.
-v, --verbose
Increase the program's verbosity. Multiple '-v's may be used:
    With none: minimal messages
    1: progress reports at each stage
    2: output of extraction and shell commands are visible
    3: all file operations are reported
-V, --version
Print the program's version.
--iw name logfile
Create a package according to an installwatch log file. There is no rules file involved in this operation. The files, directories, and symbolic links mentioned in the log file will be recreated in $PKGDIR. Then the package will be created, following the usual preferences and options regarding stripping, symbolic link creation, and the like.

This is not a good way to make a package, but it can be useful as a tool for analyzing how certain programs try to install themselves.


The rules file may define any or all of the following functions.

Usually, nothing happens here.

$SOURCE, $NAME, $PKGNAME, $VERSION, and $TMPDIR have been set. $TMPDIR has been created. $SRCDIR and $PKGDIR have not been set. The working directory is the directory from which autopkg was run (in other words, unchanged).

This is where most of the rules file's work takes place. Configuring, compiling and installing to $PKGDIR should be accomplished here.

The source has been extracted/copied to $SRCDIR. $PKGDIR has been created. The working directory is $SRCDIR, and will remain so until the program is finished.

Usually, nothing happens here. You could chmod certain programs if you want them to be suid or sgid.

The object files have been stripped (if $OPTIONS{STRIP} was true). The files' permissions have been set to %DEFPERMS, if $OPTIONS{SETPERMS} was true.

A place to print any important messages. The last word.


The following global variables are primarily meant to provide information to the rules, rather than to be modified:

Directory from which autopkg was run
Directory from which the source was extracted (if an archive) or copied (if a directory).
The directory of the rules file that's in use. It might contain patches or other related files in $RULESDIR/patches, for example.
Where the files should be installed. The directory whose subdirectories will be tarred up and become the package.
The file or directory name that was given on the command line (fully qualified).
The temporary directory to which source will be extracted/copied,
Where the source has been extracted/copied. If it extracted into a single subdirectory, $SRCDIR will be that directory. Otherwise (e.g., an unfriendly tarball), $SRCDIR will be the directory containing everything extracted (as if you had tar xzvf'd the source and not changed dirs after).

The following global variables may be modified whenever necessary. Many of them change the main program's behavior.

Architecture identification string. It is only used to create the package's filename via $PKGFORMAT (below). Default: autopkg tries to guess the architecture from the output of `uname -m`. On x86 systems, it defaults to 'i486'.
Package build number. It is only used to create the package's filename via $PKGFORMAT. Default: 1.
Initials or other identification string of the packager. It is used to create the package filename via $PKGFORMAT. The best place to set this is in the rcfile. Default: anon.
The name of the program being packaged; parsed from $SOURCE or taken from a -n option. The main program uses it to set $PKGNAME to its default, $NAME.tgz, and to find a description file in $DESCDIR.
Parsed from $SOURCE. Not used by the main program, but you could use it if you modify $PKGNAME.
$vermajor, $verminor, $verpatchlevel
Parsed bits of $VERSION. ``2.11.4pre6'' would result in $vermajor eq '2', $verminor eq '11', and $verpatchlevel eq '4pre6'.
Version control. $VERSIONS{$VERSION} will be examined just after pre_extract() is called and the appropriate action taken: 'ok' (continue), 'warn:message' (print warning and pause), or 'abort:<message>' (don't build package). $OPTIONS{UNKNOWNVER} may also be set to one of these values, especially in the run control file.

See the VERSION CONTROL section for more information.

A string to determine the filename of the package. Within it, NAME, VERSION, ARCH, BUILD, and ID will be replaced with the contents of their respective variables to construct the filename. However, if $PKGNAME has been set, $PKFORMAT will not take effect. It defaults to NAME.tgz. NAME-VERSION-ARCH-BUILDID.tgz is a common alternative. The most likely place to change this variable is the rcfile.
Set this variable to the package's desired filename. Doing so will override $PKGFORMAT.
The keys are filenames, relative to $PKGDIR. The values are references to arrays with two members: the user and the group. They may be numeric or names. Examples:
  $OWNERSHIP{"var/cache/pdnsd/pdnsd.cache"} = ['nobody', 'nobody'];
  $OWNERSHIP{"usr/bin/pdnsd"} = [0, 'daemon'];

This hash exists because the program isn't normally run as root, so ownerships must be set by the main program while internally creating the tarfile. See also the DEFOWN setting in %OPTIONS.

This hash lets you set the permissions of all files in a directory that have certain permissions, to a certain user/group ownership. Each key is a directory. Each value is a reference to an array of user, group, permissions. Example:
  $DIROWNER{'usr/bin'} => ['root', 'bin', 0550]

This would cause every file in the usr/bin directory, whose permissions are at least 550, to have an owner of root and group of bin.

The .autopkgrc file is the logical place to set these values. The %OWNERSHIP hash overrides this.

It only affects files that pass the -f test.

Default permissions. If $OPTIONS{SETPERMS} is true, the program will set permissions according to %DEFPERMS after make_package() is called.

There are exactly three keys: exec, data, and dir. Their default values:

  'exec' => 0755
  'data' => 0644
  'dir'  => 0755

The program distinguishes between 'exec' and 'data' files by using the -x file test. If true, the file's mode will be set to $DEFPERMS{exec}, otherwise to $DEFPERMS{data}.

You can delete any of exec, data, or dir to prevent that kind of permission setting.

There is no %PERMISSIONS hash for individual files. Just call chmod() yourself during pre_package() -- especially if you want specific programs to be suid or sgid.

A directory where sources are kept. When set, autopkg will look for source tarballs there. The run control file is the most likely place to set this. It allows the storage of source in a single location, and the command used to build one need only be the beginning of the source tarball's filename. For example, if gqview-0.11.0.tar.gz were in ~/sources, and ~/.autopkgrc had the following line:
  $SOURCES = '/home/user/sources';

This command will build gqview:

  autopkg gqview
The directory where description files are found. It defaults to ``$RULESDIR/descriptions''. These files must be in the standard slack-desc format, because autopkg will not try to reformat them.

Whenever the file ``$DESCDIR/$NAME'' is found, it will be automatically be used as the install/slack-desc file unless overridden by one of the following circumstances:

  1. The function include_desc() has been called
  2. $OPTIONS{USE_DESCDIR} has been set to 0

Note that the presence of the file ``$DESCDIR/$NAME'' will override $OPTIONS{USE_INSTALLED_DESC}.

Descriptions may use tokens like @VERSION@ to insert the contents of $VERSION in a slack-desc. Preexisting global variables can be used in this way. However, you cannot declare a variable in the rcfile or a rules file, and expect it to be available to a description.

Therefore, to make a string available for use in descriptions, put a value in %SUBS. For example, to put the name of the builder in descriptions, include something like the following in ~/.autopkgrc:

  $SUBS{builder} = 'Mike';

Then, put a line like the following in each description file:

  galeon: built by @builder@

This only applies to description files in $DESCDIR. See the DESCRIPTIONS section for more information.

A short string intended to be passed to make. It defaults to '-j2'. Rules files should make use of it whenever appropriate, e.g.:
  shellcmd("make $opt_jobs", 'make');

It may be modified if distcc is in use; see the distcc support section.

A short string identifying the preferred C compiler. Ordinarily, it's an empty string. If distcc is in use, it may be changed to 'CC=distcc'. It may come in handy in one of several places, depending on the source being compiled. Therefore, it is used in rules files. Example:
  shellcmd("$def_cc ./configure --prefix=/usr", 'configure');

See the distcc support section for more information.

Default: [0, 0]. The default owner and group for all files. The value is in the same format as %OWNERSHIP: a reference to an array with numeric or named user/group ids.
Default: directory from which autopkg was run. It is the directory to which the finished package will be written. The run control file is the most likely place to set this. The -d/--destdir command line option will override it.
Default: 'ok'. The value may also be 'warn:message' or 'abort:message'. What to do when the target's version isn't mentioned in %VERSIONS.

Note: If you set any values in %VERSIONS, but do not set $OPTIONS{UNKNOWNVER}, it is treated as if its value were 'warn'.

Default: true. Whether to make an installation script for the creation/removal of symbolic links, which will be included in the package tarball. If it's false, the symlinks will simply be included as is.
Default: true. Whether to set file ownerships according to $OPTIONS{DEFOWN}. %OWNERSHIP and %DIROWNERS will be effective regardless of this.
Default: true. Whether to set file and directory permissions according to %DEFPERMS, after calling build().
Default: true. Whether to strip object files with strip --strip-unneeded.
Default: 0. It is an integer between 0 and 3, with 0 being rather quiet, and 3 being highly verbose. This value will be overridden by any -v options on the command line. The run control file is the most likely place to set this.
Default: true. Whether to use the description file from the description directory as the install/slack-desc file.
Default: false. Whether to look in /var/log/packages for an install log of the same name as the package being built, and try to extract a description and use that as install/slack-desc.
Default: true. Whether to include slack-desc editing instructions whenever the program has to construct such a file. This option takes effect when include_desc() is called or $OPTIONS{USE_INSTALLED_DESC} is used, but not when a description file from the $DESCDIR directory is used (since autopkg will just copy the file).
Default: false. Whether to check for a perllocal.pod file and handle it. Handling it consists of moving it to the install directory, and setting up scripts so that it will be dealt with at install time. The scripts will remove any previous mention of the package from the system perllocal.pod file before appending the package's.

This will prevent multiple mentions of the package from building up in perllocal.pod, even if you remove and reinstall the package, or upgrade it. It will still be mentioned in perllocal.pod when the package is removed, but given the limitations of the perllocal.pod file, there's not much that can be done about that.

If you don't enable this, and make a package with perllocal.pod and don't handle it yourself, the system perllocal.pod will be overwritten when the package is installed. That's not good.

The directories it looks in can be determined by running:

  perl -V:installarchlib  -V:installsitearch

The scripts will cause the ``installarchlib'' directory to be used at install time, regardless of where the perllocal.pod file was found. This is done because perldoc, when searching for perllocal.pod, will look first in the installarchlib directory, and then in the installsitearch directory. And if it finds it in the first directory, it will ignore it in the second.

Default: nothing. A reference to an array of directories, given relative to $PKGDIR, that will be fed to the ziptree() function.


The main program makes several helpful functions available to the rules. Most of them operate relative to $PKGDIR as a destination, and $SRCDIR as a source. This is for the sake of convenience. The subs in the more flexible File::Path, File::Copy, and File::Find packages are also already available.

shellcmd(command, [purpose])
Run a shell command. You are free to call system() or use backticks as you like, but progress and error messages will be handled in a consistent manner if you call shellcmd(). The purpose should be a very short description of the command's purpose, like ``make'', or ``make install''.
include_desc(description, [instructions])
Put some text in the install/slack-desc file. The description should be a single scalar whose lines are separated by newlines and do not include the package name as a prefix. This function will prepend the prefix to each line before creating the file, and add blank lines, if needed, to bring the number of lines up to 11. The instructions normally seen in slack-desc files will be included according to $OPTIONS{DESC_INSTRUCTIONS} (which defaults to true), unless overridden by passing a second parameter to this function.
mkdirs(dir, dir, ...)
Make some directories within $PKGDIR. Don't call this during pre_extract(), because $PKGDIR hasn't been made by that time. Example:
  mkdirs('usr/bin', 'usr/share/funkyprog');
copyfiles(destdir, file, file, ...)
Copy some files to destdir. destdir is relative to $PKGDIR, and the files are relative to $SRCDIR. The directory will be created if necessary. Example:
  copyfiles('usr/doc/funkyprog', 'README', 'doc/funky.html');
docfiles(file, file, ...)
Shortcut to copy the given files to $PKGDIR/usr/doc/$NAME-$VERSION.
Looks for a source archive in $SOURCES beginning with name. Extracts it into $SRCDIR, and returns an array with two items: the directory it extracted to (e.g. /tmp/fileXXXX/name-ver) and its version.
dbugout(level, message, message, ...)
Print some messages, if the current verbosity level (set with -v) is at or above the given level.
getconfig(request, default, program, program, ...)
Retrieve a configuration value from a name-config program, or return the default if none of the programs supplied a value. This function suppresses any ``not found'' error messages.
  my $prefix = getconfig(qw(prefix /opt/gnome gnome-config gtk-config));

The above example will try to get a prefix, running `gnome-config --prefix`, and `gtk-config --prefix` if gnome-config wasn't found, or finally returning '/opt/gnome' as a last resort.

preserve_config(file1, file2, ...)
This function automates preservation of system configuration files. Each file passed to the function (which may be relative to $PKGDIR) will have the following things done to it:
  • It will be renamed to ``$''
  • The installaion script will have code added to check for the existence of a preexisting file of the same name. If that file is not already present, the new one will be copied to the working filename. If the file already exists, and has the same content, the new file will be erased; otherwise it will be left for the system administrator to consider.



The resulting package will contain a file named 'etc/', which will be copied to /etc/foo.conf by if and only if /etc/foo.conf is not already present.

greps every file in $PKGDIR or the directory passed to it for $PKGDIR. If a ``.packlist'' file is found to contain ``$PKGDIR'', it will be read, fixed, and rewritten with the string removed. If a ``perllocal.pod'' file is found to contain it, it will be ignored, as these are likely to be fixed by handle_perllocal_pod() later. If any other file is found to contain ``$PKGDIR'', it is a fatal error.

This sub is useful when dealing with Perl modules that are installed via the ``perl Makefile.PL PREFIX=$PKGDIR/usr; make; make test; make install'' routine. Such modules are not designed to be installed to any place other than the place from which they will be used. Thus, you cannot be sure whether they will expect to find things under ``$PKGDIR/...'' and hardcode this directory in various places.

checkdupes(file, file, ...)
Check for duplicates of the given file(s), in the package directory. Any duplicate that is found will be replaced with a symbolic link to the filename passed to this function. This function looks in the same directory as the file(s) passed to it, and checks first the size, then the MD5 checksum, of every other file in that directory. If they both match to the original file, the file being examined will be taken to be a duplicate, and replaced.

It can be useful for certain source packages that install duplicate copies of their executables. For example, after doing something like the following:

  shellcmd("make install DESTDIR=$PKGDIR", 'make install');

The following duplicate executables may have been installed:


It would be useful, in this case, to remove $PKGDIR/usr/bin/foo and make it into a symbolic link to foo-2.7. This will save space, and preserve the ability to refer to a specific version of foo. The call to this function would be:

Get the contents of a file. Handy if you feel the need to munge certain shell scripts or default conf files. Not relative to $SRCDIR, however, so specify that if you need to.
stowfile(filename, contents, [mode])
Save data to a file. mode is optional. Handy if you've slurped and munged a file. Not relative to $PKGDIR, so specify that if you have to.
ziptree(dir, dir, ...)
Run gzip -9 on each file found in each dir. The directories are given relative to $PKGDIR: do not include the leading /. Symbolic links pointing to any file gzipped in this way will be adjusted.

This function is useful for compressing man pages. It may be more convenient to set $OPTIONS{ZIPDIRS} to the standard set of manpage directories than to call this function directly.

Apply all appropriate patches from a patch directory. The directory defaults to $RULESDIR/patches. All patches matching $NAME-$VERSION-*patch will be applied, for example curl-7.9-extralovin-patch or galeon-0.14.2-wildbrowsing-patch. Patches may be compressed with gzip or bzip2.

The patches must be applicable with the -p1 option when in the main source directory. The following command would create such a patch:

  ~$ diff -u blackbox-0.61.1-orig/src/ blackbox-0.61.1/src/ >
choke(message, message, ...)
Abort with error messages.


Normally, an installation script to create symbolic links will be placed in install/ The rules may write their own install/ script. If the token @SYMLINKS@ is present, it will be replaced with the commands to create symbolic links. If not, they will be prepended to the beginning of the script.


After version 8.0, Slackware's package management utilities gained the ability to use description files within packages. autopkg offers three methods of including these files in packages it creates.

Method #1 - call the function include_desc() from the rules file. See the AVAILABLE FUNCTIONS section for more information about this function.

Method #2 - from the descriptions directory. If a file named ``$DESCDIR/$NAME'' is found, it will be treated as a slack-desc file and included in the package by default. This can be overridden, though. See the VARIABLES section for more information.

Tokens in the form @NAME@ will be replaced. The value of $SUBS{NAME} will be used if it exists. Otherwise, a global scalar variable $NAME will be used. @VERSION@ would be replaced with the value of $VERSION. If you want to establish additional strings to be used in descriptions, put them in %SUBS -- Perl's scoping rules prevent variables declared in eval() from being used this way.

Method #3 - using a description from an already installed package of the same name. This is probably the most convenient method. It is not enabled by default. Set $OPTIONS{USE_INSTALLED_DESC} to true, probably from the .autopkgrc file, to enable it.


The $VERSION variable is parsed from the archive filename or directory passed on the command line. Values in %VERSIONS or $OPTIONS{UNKNOWNVER} won't be examined until pre_extract() has been called. That sub (or even code outside a sub) could parse the filename and change $VERSION, if the target's filename is odd.

By default, the main program mostly ignores $VERSION and tries to build the package. When values are set in %VERSIONS, the program will examine them and $VERSION, and may pause or abort the package building process.

Important: if %VERSIONS has some values, but $OPTIONS{UNKNOWNVER} isn't set, it will be treated as if its value were 'warn'. Rules can therefore define a few versions known to work, and any other versions will pause the process.


Autopkg can be set up to use distcc when it's available, and work without it otherwise.

STEP 1: Install distcc normally. Ensure that the environment variable DISTCC_HOSTS is defined.

STEP 2: Make sure your .autopkgrc file includes that snippet of code that modifies $opt_jobs and $def_cc. If you're using a copy of the latest sample.autopkgrc file from the autopkg distribution, it's in there.

STEP 3: Make sure the rules files are using the variables $opt_jobs and $def_cc in the appropriate places. $opt_jobs is rather easy; it is used as an option to make:

  shellcmd("make $opt_jobs", 'make');

There are at least three kinds of situations regarding $def_cc, however.

First, a standard configure script will look at the environment variable CC, so $def_cc precedes it:

  shellcmd("$def_cc ./configure --prefix=/usr", 'configure');

Often, a package that doesn't use configure, or uses a nonstandard configure, will have CC defined in the makefile. In that case, you just override it when invoking make:

  shellcmd("make $opt_jobs $def_cc", 'make');

The third situation is where the author of the package hasn't made it easy for you. Good luck!

The above examples will work whether or not $def_cc has any text.


The run control file is ~/.autopkgrc. It is perl, which will be eval'd just before the command line options are parsed.


For GNU autoconf'd software with the install-strip target (many packages will be built like this):

  sub build {
    shellcmd("$def_cc ./configure --prefix=/usr", "configure");
    shellcmd("make $opt_jobs", "make");
    shellcmd("make install-strip DESTDIR=$PKGDIR",
      "make install");
    $OPTIONS{STRIP} = 0;

For mpg123, which doesn't install its own documentation:

  $VERSIONS{'0.59r'} = 'ok';
  sub build {
      README TODO README.remote));
    shellcmd("make linux", "make");
    shellcmd("make install PREFIX=$PKGDIR/usr", "make install");


Rules files.
The run control file.


This program refuses to run as root. By running this program as a user, you allow filesystem permissions to stop the packaging process if, for example, `make install DESTDIR=$PKGDIR' starts trying to write directly to /usr.

The majority of programs are easy to package with autopkg. But sometimes you come across a stubborn one that expects to install itself partway (as root), and compile something against the installed bit. autopkg is not particularly suited to packaging these, and you might have to fall back to something like checkinstall or protopkg. Of course, you then lose the advantage of a dry-run install.


Joshua Swink <>


checkinstall, installwatch, makepkg(8), protopkg(8)


November 6, 2004