|
autopkg(8) |
System administration |
autopkg(8) |
autopkg - create Slackware packages from source
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.
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
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.
$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).
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.
The object files have been stripped (if $OPTIONS{STRIP} was true). The files' permissions have been set to %DEFPERMS, if $OPTIONS{SETPERMS} was true.
The following global variables are primarily meant to provide information to the rules, rather than to be modified:
The following global variables may be modified whenever necessary. Many of them change the main program's behavior.
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.
$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.
$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.
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.
$SOURCES = '/home/user/sources';
This command will build gqview:
autopkg gqview
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}.
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.
shellcmd("make $opt_jobs", 'make');
It may be modified if distcc is in use; see the distcc support section.
shellcmd("$def_cc ./configure --prefix=/usr", 'configure');
See the distcc support section for more information.
Note: If you set any values in %VERSIONS, but do not set $OPTIONS{UNKNOWNVER}, it is treated as if its value were 'warn'.
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).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.
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.
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''.
mkdirs('usr/bin', 'usr/share/funkyprog');
copyfiles('usr/doc/funkyprog', 'README', 'doc/funky.html');
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.
Example:
preserve_config('etc/foo.conf')
The resulting package will contain a file named 'etc/foo.conf.new', which will be copied to /etc/foo.conf by doinst.sh if and only if /etc/foo.conf is not already present.
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.
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:
$PKGDIR/usr/bin/foo-2.7 $PKGDIR/usr/bin/foo
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:
checkdupes("usr/bin/foo-$vermajor.$verminor");
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.
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/Window.cc blackbox-0.61.1/src/Window.cc >
blackbox-0.61.1-mystery-patch
Normally, an installation script to create symbolic links will be placed in install/doinst.sh. The rules may write their own install/doinst.sh 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 {
docfiles(qw(README COPYING INSTALL AUTHORS));
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 {
docfiles(qw(BENCHMARKING BUGS CHANGES COPYING INSTALL JUKEBOX
README TODO README.remote));
shellcmd("make linux", "make");
shellcmd("make install PREFIX=$PKGDIR/usr", "make install");
}
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 <yathster@yahoo.com>
checkinstall, installwatch, makepkg(8),
protopkg(8)
|
November 6, 2004 |
autopkg(8) |