Slackware Linux Essentials - Chapter 18 Slackware Package Management
Warning: file_get_contents(http://ecs.amazonaws.com/onca/xml?Service=AWSECommerceService&AWSAccessKeyId=1TJ8QTQ6ZFCVAJ3X1T02&AssociateTag=ii0c3-20&Operation=ItemSearch&SearchIndex=Books&ResponseGroup=Small,Images&Keywords=archive) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 400 Bad Request in /home/manusia2/public_html/wp-content/plugins/amazonfeed/php/amazonfeed.class.php on line 271
A software package is a bundle of related programs that are ready for you to install. When you download a source code archive, you have to configure, compile, and install it by hand. With a software package, this has already been done for you. All that you have to do is install the package. Another handy feature of using software packages is that it is very easy to remove and upgrade them, if you so desire. Slackware comes with programs for all your package management needs. You can install, remove, upgrade, make, and examine packages very easily.
There’s a myth that’s been going around ever since RedHat debuted RedHat Package Manager, that Slackware has no package management tool. This simply couldn’t be further from the truth. Slackware has always included a package manager, even before RedHat existed. While not as full-featured or as ubiquitous as rpm (or for that matter deb), pkgtool and its associated programs are every bit as good at installing packages as rpm. The truth about pkgtool is not that it doesn’t exist, but that it doesn’t do any dependency checking.
Apparently many people in the Linux community think that a packager manager must by definition include dependency checking. Well, that simply isn’t the case, as Slackware most certainly does not. This is not to say that Slackware packages don’t have dependencies, but rather that its package manager doesn’t check for them. Dependency management is left up to the sysadmin, and that’s the way we like it.
18.1 Overview of Package Format
Before learning the utilities, you should become familiar with the format of a Slackware package. In Slackware, a package is simply a tar archive file that has been compressed with gzip. Packages are built to be extracted in the root directory.
Here is a fictitious program and its example package:
./ usr/ usr/bin/ usr/bin/makehejaz usr/doc/ usr/doc/makehejaz-1.0/ usr/doc/makehejaz-1.0/COPYING usr/doc/makehejaz-1.0/README usr/man/ usr/man/man1 usr/man/man1/makehejaz.1.gz install/ install/doinst.sh
The package system will extract this file in the root directory to install it. An entry in the package database will be created that contains the contents of this package so that it can be upgraded or removed later.
Notice the install/ subdirectory. This is a special directory that can contain a postinstallation script called doinst.sh. If the package system finds this file, it will execute it after installing the package.
Other scripts can be embedded in the package, but those are discussed more in detail in Section 18.3.2 below.
18.2 Package Utilities
There are four main utilities for package management. They perform installation, removal, and upgrades of packages.
18.2.1 pkgtool
pkgtool(8) is a menu-driven program that allows installation and removal of packages. The main menu is shown in Figure 18-1.
Figure 18-1. Pkgtool’s main menu.
Installation is offered from the current directory, another directory, or from floppy disks. Simply select the installation method you want and pkgtool will search that location for valid packages to install.
You may also view a list of installed packages, as shown in Figure 18-2.
Figure 18-2. Pkgtool view mode
If you want to remove packages, select the remove option and you will be presented with a checklist of all the installed packages. Flag the ones you want to remove and select OK. pkgtool will remove them.
Some users prefer this utility to the command line utilities. However, it should be noted that the command line utilities offer many more options. Also, the ability to upgrade packages is only offered through the command line utilities.
18.2.2 installpkg
installpkg(8) handles installation of new packages on the system. The syntax is as follows:
# installpkg option package_name
Three options are provided for installpkg. Only one option can be used at a time.
Table 18-1. installpkg Options
Option
Effects
-m
Performs a makepkg operation on the current directory.
-warn
Shows what would happen if you installed the specified package. This is useful for production systems so you can see exactly what would happen before installing something.
-r
Recursively install all packages in the current directory and down. The package name can use wildcards, which would be used as the search mask when recursively installing.
If you pass the ROOT environment variable before installpkg, that path will be used for the root directory. This is useful for setting up new drives for your root directory. They will typically be mounted to /mnt or something other than /.
The installed package database entry is stored in /var/log/packages. The entry is really just a plain text file, one for each package. If the package has a postinstallation script, it is written to /var/log/scripts/.
You may specify several packages or use wildcards for the package name. Be advised that installpkg will not tell you if you are overwriting an installed package. It will simply install right on top of the old one. If you want to ensure that old files from the previous package are safely removed, use upgradepkg.
18.2.3 removepkg
removepkg(8) handles removing installed packages from the system. The syntax is as follows:
# removepkg option package_name
Four options are provided for removepkg. Only one option may be used at a time.
Table 18-2. removepkg Options
Option
Effects
-copy
The package is copied to the preserved packages directory. This creates a tree of the original package without removing it.
-keep
Saves temporary files created during the removal. Really only useful for debugging purposes.
-preserve
The package is removed, but copied to the preserved packages directory at the same time.
-warn
Shows what would happen if you removed the package.
If you pass the ROOT environment variable before removepkg, that path will be used for the root directory. This is useful for setting up new drives for your root directory. They will typically be mounted to /mnt or something other than /.
removepkg looks at the other installed packages and only removes files unique to the package you specify. It will also scan the postinstallation script for the specified package and remove any symbolic links that were created by it.
During the removal process, a status report is displayed. After the removal, the package database entry is moved to /var/log/removed_packages and the postinstallation script is moved to /var/log/removed_scripts.
Just as with installpkg, you can specify several packages or use wildcards for the package name.
18.2.4 upgradepkg
upgradepkg(8) will upgrade an installed Slackware package. The syntax is as follows:
# upgradepkg package_name
or
# upgradepkg old_package_name%new_package_name
upgradepkg works by first installing the new package and then removing the old package so that old files are no longer around on the system. If the upgraded package name has changed, use the percent sign syntax to specify the old package (the one that is installed) and the new package (the one you are upgrading it to).
If you pass the ROOT environment variable before upgradepkg, that path will be used for the root directory. This is useful for setting up new drives for your root directory. They will typically be mounted to /mnt or something other than /.
upgradepkg is not flawless. You should always back up your configuration files. If they get removed or overwritten, you’ll want a copy of the originals for any needed repair work.
Just as with installpkg and removepkg, you can specify several packages or use wildcards for the package name.
18.2.5 rpm2tgz/rpm2targz
The Red Hat Package Manager is a popular packaging system available today. Many software distributors are offering their products in RPM format. Since this is not our native format, we do not recommend people rely on them. However, some things are only available as an RPM (even the source).
We provide a program that will convert RPM packages to our native .tgz format. This will allow you to extract the package (perhaps with explodepkg) to a temporary directory and examine its contents.
The rpm2tgz program will create a Slackware package with a .tgz extension, while rpm2targz creates an archive with a .tar.gz extension.
18.3 Making Packages
Making Slackware packages can be either easy or difficult. There is no specific method for building a package. The only requirement is that the package be a tar gzipped file and if there is a postinstallation script, it must be /install/doinst.sh.
If you are interested in making packages for your system or for a network that you manage, you should have a look at the various build scripts in the Slackware source tree. There are several methods we use for making packages.
18.3.1 explodepkg
explodepkg(8) will do the same thing that installpkg does to extract the package, but it doesn’t actually install it and it doesn’t record it in the packages database. It simply extracts it to the current directory.
If you look at the Slackware source tree, you will see how we use this command for “framework” packages. These packages contain a skeleton of what the final package will look like. They hold all the necessary filenames (zero-length), permissions, and ownerships. The build script will cat the package contents from the source directory to the package build directory.
18.3.2 makepkg
makepkg(8) will package up the current directory into a valid Slackware package. It will search the tree for any symbolic links and add a creation block to the postinstallation script for creating them during the package install. It also warns of any zero-length files in the package tree.
This command is typically run after you have created your package tree.
18.3.3 SlackBuild Scripts
Slackware packages are built in many different ways by necessity. Not all software packages are written by their programmers to compile the same way. Many have compile time options that are not all included in the packages Slackware uses. Perhaps you need some of this functionality; you’ll need to compile your own package then. Fortunately for many Slackware packages, you can find SlackBuild scripts in the package’s source code.
So what is a SlackBuild script? SlackBuild scripts are executable shell scripts that you run as root to configure, compile, and create Slackware packages. You can freely modify these scripts in the source directory and run them to create your own versions of the default Slackware packages.
18.4 Making Tags and Tagfiles (for setup)
The Slackware setup program handles installation of the software packages on your system. There are files that tell the setup program which packages must be installed, which ones are optional, and which ones are selected by default by the setup program.
A tagfile is in the first software series directory and is called tagfile. It lists the packages in that particular disk set and their status. The status can be:
Table 18-3. Tagfile Status Options
Option
Meaning
ADD
The package is required for proper system operation
SKP
The package will be automatically skipped
REC
The package is not required, but recommended
OPT
The package is optional
The format is simply:
package_name: status
One package per line. The original tagfiles for each software series are stored as tagfile.org. So if you mess up yours, you can restore the original one.
Many administrators prefer writing their own tagfiles and starting the installer and selecting “full”. The setup program will read the tagfiles and perform the installation according to their contents. If you use REC or OPT, a dialog box will be presented to the user asking whether or not they want a particular package. Therefore, it is recommended that you stick with ADD and SKP when writing tagfiles for automated installs.
Just make sure your tagfiles are written to the same location as the originals. Or you can specify a custom tagfile path if you have custom tagfiles.
Tags: archive, database, manage, pop, redhat, slackware, Slackware Linux Essentials, software