< Free Open Study > |
Software Installation Tools
This chapter has described a variety of tools and techniques for software installation. This section will describe the following tools and discuss the ones provided by most distributions:
GNU autoconf
Red Hat's RPM
Slackware's tarballs
Debian's dpkg format
After reading this material, users will be familiar with how software is built and installed on a variety of distributions. This section probably isn't quite a complete reference, but it can be viewed as a sort of "quick guide" for using these tools. The most common uses are covered, but readers who need more extensive information should consult the documentation for the specific tools.
Using GNU autoconf
Many open source packages use the GNU autoconf tools to configure the software's compile-time options. GNU autoconf works by generating standard Makefiles from templates produced by the developers of the software. The auto-conf tools scan a system, looking for the presence or absence of specific features by compiling small test programs. The Makefiles that it generates are then used to automate the actual compilation of the software.
GNU autoconf can be somewhat arcane to write templates for; fortunately, only the software developers have to worry about that, and the tools are fairly straightforward for users who are only interested in building a package. Usually, there will be a program called "configure" in the top directory of the source code tree; users simply run ./configure and the program will examine the system and construct Makefiles, header files, and similar files used by the make tool and by the source code.
The ./configure program generally takes a number of arguments. The most common of these is the –prefix option, which sets the destination directory that the software will be installed into; for example, the command ./configure –prefix=/usr/local/my-software-1 will configure the software so that it is installed into /usr/local/my-software-1.0. Many packages support their own options via configure; users can check what options are available by executing the command ./configure –help. After the software has been configured in this way, users simply run make, which will build the software, and usually make install to complete the installation. A given package's documentation will explain the specific compile-time configuration options for that package, but Table 7-1 lists some common parameters used by GNU autoconf.
OPTION | MEANING |
|---|---|
| Displays the list of arguments and options supported by this package |
| Causes the software to be installed in the directory [path] |
| Specifies the architecture and platform of the computer building the software; for example, alphaev56-unknown-linux-gnu or i686-unknown-linux-gnu; used to specify that the software should be built for a different architecture than the default |
| Adds [path] to the list of directories containing header files or libraries for the build process |
| Activates the option named [option] in the software |
| Instructs the build process to look for the package named [package] in the directory [path]; for example, –with-openssl=/usr/local/openssl-0.9.5a |
However, some packages treat a prefix of /usr as a special case. These packages will place binaries and libraries in /usr/bin and /usr/lib, but will place configuration files in /etc (rather than /usr/etc as might be expected). Watch out for these programs! To override this behavior, you can probably add an option such as –config-prefix=/usr/etc.
GNU autoconf is an extremely powerful tool for writing portable software (that is, software that runs on multiple operating systems) since it can customize a Makefile for almost any Unix-like system. Because it's so powerful, it's also very widely used. These days, you'd be hard-pressed to find an open source software package that didn't use these tools! A working understanding of the autoconf tools is a huge benefit to any user or administrator of a Linux-based system.
Using Red Hat's Tools
The packaging system used by Red Hat Linux—the Red Hat Package Manager (RPM)—was described in Chapter 4. That chapter briefly mentioned the support RPM has for source packages. This section will describe that functionality in more detail.
RPMs and Architectures
Each RPM package has an "architecture" associated with it. Normally, this architecture denotes the hardware platform for which the package was compiled; for example, a .i386.rpm package is an RPM compiled for the Intel platform. A source RPM has the extension .src.rpm. Whereas a binary RPM is obviously only useful on platforms for which it was compiled, a source RPM can be built into a binary RPM and so is useful for a variety of tasks.
Construction of Source RPMs
Typically, a source RPM is constructed to match the configuration of a binary RPM. For example, along with the actual installation CDs, Red Hat also ships CDs containing source RPMs for each package included with the system. When built, these source RPMs will produce RPMs just like the ones included on the installation CDs. That is, rebuilding all the source RPMs will duplicate all the RPMs on the CDs. This is useful, for example, in building a copy of Red Hat Linux on a platform for which Red Hat does not deliver a distribution (though in practice it's seldom that simple).
Each source RPM is built with a specific configuration. That is, the contents of the source RPM are set up with a predetermined set of compile-time options.
How these options are specified varies by the software being packaged; the most common method, as mentioned earlier in this chapter, is through GNU autconf. These compile-time options are specified in RPM specification files with extensions of .spec. The .spec files can be customized to alter the configuration of an RPM.
RPM Commands
The RPM command can be used to build binary RPMs from source, and there are generally two ways to accomplish this. The quickest and simplest method is to rebuild a source RPM into a binary package with its default configuration. This can be accomplished with the command rpm –rebuild <filename>.
The rpm –rebuild command recompiles a source package with its default configuration. In cases where a source RPM's settings need to be customized, a somewhat lengthier process can be used. Each source RPM usually contains a tarball containing the software, the specification file for the RPM, and sometimes supporting files (such as patches to be applied to the software). Installing a source RPM (via the usual rpm –install command described in Chapter 4) causes these files to be extracted and installed, and then they can be customized.
Contents of the /usr/src/redhat Directory
Installing a source RPM on a Red Hat system causes its contents to be placed in the /usr/src/redhat directory. This directory contains several subdirectories; the uses of these directories are described in Table 7-2.
DIRECTORY | CONTENTS |
|---|---|
BUILD | Separate, temporary scratch subdirectories for packages as they are built from source code |
RPMS | Completed (i.e., compiled) binary RPM packages of source RPMs that were successfully built |
SOURCES | Source code tarballs and patches used to build software extracted from source RPMs that are installed |
SPECS | Specification files for building binary RPM packages from source code installed in SOURCES |
SRPMS | Copies of source RPMs (SRPMS) that have been installed, for later reference |
After a source RPM is installed, it can be customized by editing its .spec file, which will be placed in /usr/src/redhat/SPECS. After editing the RPM's .spec file, the rpm -ba <filename> command can be used to instruct RPM to build the package, including all stages. (There are several stages to an RPM build, from configuration to installation, and each phase can be specified independently, though usually this isn't necessary.) The .spec file will be examined and its contents (which are much like a script) will be executed to compile the package. During this process, it will attempt to locate the tarball for the source code in /usr/src/redhat/SOURCES, and when the process is complete, it will place the new binary RPM in /usr/src/redhat/RPMS.
In most cases, system administrators and users need to alter a few configuration options, such as disabling a compile-time feature or altering a path. These needs can be met by the preceding techniques. For more complicated tasks, though, users should consult Red Hat's extensive RPM documentation at http://www.redhat.com. (Alternatively, the Maximum RPM reference book is included in digital form on the documentation CD of recent Red Hat Linux distributions.)
Using Slackware's Tools
The Slackware Linux distribution was discussed in Chapter 5. Slackware's packaging mechanism is based on simple tarballs, which are standard compressed Unix tar (Tape Archive) files. Typically these files have extensions of .tar.gz or .tar.Z. Since it uses such a simple format, Slackware has limited capability to add extensive support for source code packages.
The typical method for installing a package from source code on a Slackware Linux system is therefore pretty simple. The administrator simply builds the package manually, by whatever mechanism is required, and then constructs a Slackware package from it and installs it via the standard tools. Typically, this involves running the ./configure script that is provided with most packages.
For example, you might install the hypothetical package my-software to the directory /opt/my-software-1.0 by following these instructions:
Download the source code tarball, and consult the documentation for compile-time options.
Extract the software source code into a convenient directory, such as /usr/src/my-software. Choose a temporary directory to "install" the software to, such as /tmp/my-software-tmp/opt/my-software-1.0. This will not be the permanent location, but is instead passed to the command that follows.
Run the ./configure program with the appropriate arguments, in particular the –prefix option (e.g., ./configure –prefix=/tmp/my-software-tmp/opt/my-software-1.0).
Build the software via the make command; when it completes, "install" it into the temporary directory via the make install command.
Enter the temporary directory—that is, cd /tmp/my-software-1.0.
Create a Slackware package from the temporary directory, via a command such as makepkg /tmp/my-software-1.0.tgz. This command will create the Slackware package (which is simply a standard tarball with some extra information).
Install the newly created package via the command installpkg /tmp/my-software-1.0..
Some readers may wonder why the software was built and installed into a temporary directory such as /tmp/my-software-1.0 in steps 3 and 4. The other alternative would have been to directly install the software in its ultimate location (such as /opt, /usr/local, or the root directory). However, if this approach is used, the software will be installed in its permanent location, without the knowledge of the packaging tools. This means that the tools won't be able to uninstall, upgrade, or otherwise manage the package. Instead, the software is installed in a temporary scratch directory, so that the makepkg tool can be run to locate and consolidate all the files. When the package is installed, the tools will know about it and therefore be able to manage it. (In reality, you could always just edit the contents of /var/log/packages directly, but that's a lot of work and defeats the purpose of the tools in the first place!)
One last thing to note about the installation process is the actual temporary directory chosen. In this example, it was /tmp/my-software-tmp/opt/my-software-1.0. The reason for this is to make sure that the software is installed into its temporary directory in such a way that the makepkg tool can properly create the package. The tool will include all files and subdirectories contained in the current directory in the resulting package; thus, by installing the software into the temporary /tmp/my-software-tmp/opt/my-software-1.0 and running the command from /tmp/my-software-tmp, the package will be created so that all files are stored in opt/my-software-1.0. Since installpkg will install the files relative to the root directory, this will cause the package contents to be placed in /opt/my-software-1.0—which was the original goal. Similarly, if the goal was to install into /usr/local, meanwhile, the scratch directory would have been /tmp/my-software-tmp/usr/local.
Slackware's tools are very simple, in keeping with the Slackware philosophy. This makes them easy to use but still leaves the administrator a bit more work to do. (Compare this example for Slackware with the shorter rpm –rebuild command used on Red Hat Linux systems.) On the other hand, even though Slackware's tools may require a bit more work when building software from source code, they're a lot easier to understand and don't require as much study as more sophisticated tools.
Using Debian's Tools
Building Debian packages is accomplished using the dpkg-deb program included with Debian GNU/Linux. This tool has similarities to the approaches of both RPM and Slackware's system. Specifically, Debian's system has a custom format for archives, but it generally builds such packages by simply processing and storing up the contents of a particular directory. The custom format makes Debian's system similar to RPM, in that you can perform operations like install, uninstall, and query on packages, and the system itself keeps track of dependencies for you. However, creating such packages involves just archiving the contents of the (specially prepared) current directory, which is similar to Slackware's approach.
| Cross-Reference |
|
For example, suppose you wanted to create a Debian package for the hypothetical "my-software" package considered in the previous section on Slackware's tools. At a very high level, the step for building such a package for Debian is very similar to the seven steps outlined in the Slackware section. The main differences are that instead of using the makepkg command in step 6, you'd use the command dpkg-deb –build /tmp/my-software-1.0.deb. Similarly, once you've created the package, you would use the command dpkg -i /tmp/my-software-.0.deb to install it, rather than the installpkg command in step 7.
As you can see, creating Debian packages from source code is conceptually fairly similar to the equivalent process on Slackware Linux. On the other hand, once you have the file in hand, you can perform various queries on it (such as listing its contents, or fetching its description) as you could with an RPM. However, this story isn't quite complete, and there is another way in which Debian's system is similar to Red Hat's.
Specifically, the process just outlined omits a very important step—namely, the creation of the required files and directory for Debian archives. In order to run correctly, the dpkg-deb command expects to find a directory named "debian" as a subdirectory of the tree you wish to build into a Debian package. This directory contains several additional files, which are summarized in Table 7-3.
FILE | PURPOSE |
|---|---|
control | Contains basic information about the software being packaged, such as its version, description, and dependencies |
rules | A script used to prepare the directory's contents for packaging |
changelog | Lists a history of changes made to the package |
copyright | Identifies the copyright holder and related issues |
You've probably realized by now that when taken together, the files outlined in Table 7-3 amount to the equivalent of Red Hat's ".spec" files for RPM packages. These files are used by the dpkg-deb command to prepare the directory and construct the Debian package from its contents. Thus, while mechanically the process has similarities to Red Hat (in that it builds an archive from the contents of the current directory), it also has strong similarities to Red Hat. Clearly, there's more than one way to skin this particular cat. (Most commercial Unix flavors usually each have yet another way of tackling this problem.)
Unless you're a software developer, you may not need to create Debian packages at all. As a user, all you probably need to know about this process is that it's not as easy to rebuild a Debian package from source code as it is an RPM, since there is no ready-packaged "source .deb" akin to a "source RPM." Since this isn't a book on software development or how to build Debian packages, if you need more detail than that you should consult the Debian Project's documentation, which you can find at http://www.debian.org/doc/manuals/programmer/index.html.
No comments:
Post a Comment