Using Software in Different Formats | Fedora 6 and Red Hat Enterprise Linux Bible

There may not be RPMs available for every piece of software you want to install on your Fedora or RHEL system. Likewise, you may find that an RPM isn't configured exactly the way you would want it, so that you would be better served by building your own RPM from an RPM source code package. The following sections describe various forms in which you may encounter open source software and different ways of building and installing that software for you to use.

Understanding Software Package Names and Formats

Whenever possible, you want to install the applications you use with Fedora Core from software packages in RPM format (files with a .rpm extension). However, if an RPM isn't available, the software that you want may come in other package formats.

Say you just downloaded a file from the Internet that contains lots of names, numbers , dots, gzs, and tars. What does all that stuff mean? Well, when you break it down, it's really not that complicated.

Most of the names of archive files containing Linux applications follow the GNU-style package-naming conventions. The following example illustrates the package-naming format:

 mycoolapp-4.2.3-1.i386.rpm mycoolapp-4.2.3.tar.gz mycoolapp-4.2.3.src.tar.gz mycoolapp-4.2.3.bin.SPARC.tar.gz mycoolapp-4.2.3.bin.ELF.static.tar.gz

These examples represent several different packages of the same software application. The name of this package is mycoolapp . Following the package name is a set of numbers that represent the version of the package. In this case, it is version 4.2.3 (the major version number is 4, followed by minor version number and patch level 2.3). After the version number is a dot, followed by some optional parts , which are followed by indications of how the file is archived and compressed.

The first line shows a package that is in the RPM Package Manager ( .rpm ) format. The .i386 before the .rpm indicates that the package contains binaries that are built to run Intel i386 architecture computers (in other words, PCs). The -1 indicates the build level (the same package may have been rebuilt multiple times to make minor changes). See the sidebar "Using Binary RPMs versus Building from Source" for the pros and cons of using prebuilt RPM binary packages as opposed to compiling the program yourself.

Binaries created in RPM format are easily installed, managed, and uninstalled using Red Hat tools. This is the recommended installation method for Fedora Core and RHEL novices. Sometimes, however, building an application from source code may be preferable. Here are some arguments on both sides:

RPM - Installing applications from a binary RPM archive is easy. After the application is installed, there are both shell commands and GUIs for managing, verifying, updating, and removing the RPM package. You don't need to know anything about Makefiles or compilers. When you install a binary RPM package, RPM tools even check to make sure that other packages that the package depends on are installed. Because Red Hat has released RPM under the GPL, other Linux distributions also use it to distribute their software. Thus, most Linux applications are, or will be, available in RPM format.
Source code - Not all source-code packages are made into RPM binaries. If you use RPM, you may find yourself with software that is several versions old, when you could simply download the latest source code and run a few tar and make commands. Also, by modifying source code, you can tailor the package to better suit your needs.

Refer to Appendix A for information on getting source code for Fedora Core RPM binary packages that are included on the DVD that comes with this book. You can modify that source code yourself and rebuild the RPM binaries. The rebuilt binaries can be tuned to your hardware and include the features you want with the package. For more information on RPMs, refer to the Red Hat RPM Guide by Eric Foster-Johnson (Red Hat Press/Wiley, 2003).

In the next two lines of the previous example, each file contains the source code for the package. The files that make up the package were archived using the tar command ( .tar ) and compressed using the gzip command ( .gz ). You use these two commands (or just the tar command with the -z option) to expand and uncompress the packages when you are ready to install the applications.

Between the version number and the .tar.gz extension there can be optional tags, separated by dots, which provide specific information about the contents of the package. In particular, if the package is a binary version, this information provides details about where the binaries will run. In the third line, the optional .src tag was added because the developer wanted to differentiate between the source and binary versions of this package. In the fourth line, the .bin.SPARC detail indicates that it is a binary package, ready to run on a SPARC workstation. The final line indicates that it is a binary package, consisting of statically linked ELF format executables.

Instead of using gzip , many software packagers today use the bzip2 utility to compress their software archives. In that case, files names shown in the examples above might instead end with .bz2 or .tar.bz2 extensions.

Here is a breakdown of the parts of a package name:

name - This is generally an all-lowercase string of characters that identifies the application.
dash ( - )
version - This is shown as major to minor version number from left to right.
dot ( . )
src or bin - This is optional, with src usually implied if no indication is given.
dot ( . )
type of binary - This is optional and can include several different tags to describe the content of the binary archive. For example, i386 indicates binaries intended for Intel architectures (Pentium CPU) and SPARC indicates binaries for a Sparc CPU.
dot ( . )
archive type - Often tar is used ( .tar )
compression type - Often gzip is used (. gz )

Using Different Archive and Document Formats

Many of the software packages that are not associated with a specific distribution (such as Fedora Core or Debian) use the tar/gzip method for archiving and compressing files. However, you may notice files with different suffixes at software project sites.

Table 5-1 describes the different file formats that you will encounter as you look for software at a Linux FTP site. Table 5-2 lists some of the common document formats that are used in distributing information in Linux.

Table 5-1: Linux Archive File Formats
Open table as spreadsheet
*Format*	*Extension*	*Description*
Gzip file	.gz or .z	File was compressed using the GNU gzip utility. It can be uncompressed using the gzip or gunzip utilities (they are both the same).
Tar file	.tar	File was archived using the tar command. tar is used to gather multiple files into a single archive file. You can expand the archive into separate files using tar with different options.
Tar and Gzip file	.tgz	A common practice for naming files that are tar archives that were compressed with gzip is to use the .tgz extension.
Bzip2	.bz2	File was compressed with the bzip2 program.
Tar/compressed	.taz or .tz	File was archived with tar and compressed with the UNIX compress command.
Linux Software Map	.lsm	File contains text that describes the content of an archive.
Debian Binary Package	.deb	File is a binary package used with the Debian Linux distribution. (See descriptions of how to convert Debian to Red Hat formats later in this chapter.)
RPM Package Management	.rpm	File is a binary package used with Fedora Core. Format also available to other Linux distributions.

Table 5-2: Linux Document Formats
Open table as spreadsheet
*Format*	*Extension*	*Description*
Hypertext Markup Language	.html or .htm	File is in hypertext format for reading by a Web browser program (such as Mozilla).
PostScript	.ps	File is in PostScript format for outputting on a PostScript printer.
SGML	.sgml	File is in SGML, a standard document format. SGML is often used to produce documents that can later be output to a variety of formats.
DVI	.dvi	File is in DVI, the output format of the LaTeX text-processing tools. Convert these files to PostScript or Hewlett-Packard's PCL using the dvips and dvilj commands.
Plain text		Files in Fedora without a suffix are sometimes plain-text files (in ASCII format). (A note of Caution: A lot of the commands in Linux, such as those in /usr/bin and /usr/sbin , have no extension either. If you have a file with no extension, it's best to use the file command on it before proceeding with any operation. In fact, using file on a previously untested file can prevent problems. A .txt file full of binary code could be used to exploit a text editor and do malicious things to the system.)

If you are not sure what format a file is in, use the file command as follows :

 $  file  filename

This command tells you if it is a GNU tar file, RPM, gzip , or other file format. (This is a good technique if a file was renamed and lost its extension.)

If you would like to convert a software package from one of the formats described above, you can try the alien utility ( http:// freshmeat .net/projects/alien ). Although alien is not considered stable enough to use with important system packages, it can be a good tool for trying out some simple software packages on your Fedora system.

Building and Installing from Source Code

If no binary version of the package that you want is available, or if you just want to tailor a package to your needs, you can always install the package from source code. To begin, you can get the source code (SRPM) version of any binary packages in Fedora from Fedora software repositories (see Appendix A for details). You can modify the source code and rebuild it to suit your needs.

Software packages that are not available in RPM format are typically available in the form of a tarball (a bunch of files grouped together into a single file formatted by the tar utility) that has been compressed (typically by the gzip utility). Although the exact instructions for installing an application from a source code archive vary, many packages that are in the .bz2, .tar.bz2, .tgz, .gz and .tar formats follow the same basic procedure.

Tip

Before you install from source code, you will need to install a variety of software development packages. If you have the disk space, I recommend that you install all software development packages that are recommended during Fedora Core installation.

The following is a minimal list of C-programming software development tools:

gcc - Contains the gcc (GNU C compiler) compiler.
make - Contains the make command for making the binaries from Makefiles.
glibc - Contains important shared libraries, the C library, and the standard math library.
glibc- devel - Contains standard header files needed to create executables.
binutils - Contains utilities needed to compile programs (such as the assembler and linker).
kernel-devel - Contains the Linux kernel source code and is needed to rebuild the kernel.
rpm-build - Contains the rpmbuild utility for building the RPM binary package from source code.
libc - Contains libraries needed for programs that were based on libc 5, so older applications can run on glibc ( libc 6) systems.

Installing Software in SRPM Format

To install a source package from the Fedora Core source directory, do the following:

Refer to Appendix A for information on obtaining Fedora source code.
Download the package you want to the current directory.
Install the source code package using the following command:
```
 #  rpm -iv  packagename  *.src.rpm  
```
(Replace packagename with the name of the package you are installing.) The source is installed in the Fedora Core source tree ( /usr/src/redhat/SOURCES ). Spec files are copied to /usr/src/redhat/SPECS .
Change to the SPECS directory as follows:
```
 #  cd /usr/src/redhat/SPECS  
```
Unpack the source code as follows:
```
 #  rpmbuild -bp  packagename  *.spec  
```
The package's source code is installed to the /usr/src/redhat/BUILD/ package directory, where package is the name of the software package.
You can now make changes to the files in the package's BUILD directory. Read the README, Makefile, and other documentation files for details on how to build the individual package.

The --rebuild option to rpmbuild can be used to rebuild the rpm without installing it first. The resulting binary will be in /usr/src/redhat/RPMS/ arch , where arch is replaced by i386 or other architecture for which you are building the RPM.

Installing Software in tar.gz or tar.bz2 Formats

Here are some generic instructions that you can use to install many Linux software packages that are in the gzip or tar format:

Get the source code package from the Internet or from a CD distribution and copy it into an empty directory (preferably using a name that identifies the package).
To check the contents of your tar archive before extracting it to your hard drive, you could use the following command:
```
 #  tar tvf  package  .tar.gz  
```
Assuming the file is compressed using gzip , uncompress the file using the following command:
```
 #  gunzip  package  .tar.gz  
```
The result is that the package is uncompressed and the .gz is removed from the package name (for example, package .tar ). (If your package ends in bz2 , use the bzip2 command instead of gunzip shown above.)
From the resulting tar archive, run the tar command as follows:
```
 #  tar xvf  package  .tar  
```
This command extracts the files from the archive and copies them to a subdirectory of the current directory. (Using tar xvfz package .tar.gz you can do steps 2 and 3 in one step. For a compressed bzip2 file, run tar xvfj package .tar.bz2 instead.)
Change directories to the new subdirectory created in Step 3, as follows:
```
 #  cd  package   
```
Look for a file called INSTALL or README . One of these files should give you instructions on how to proceed with the installation. In general, the make command is used to install the package. Here are a few things to look for in the current directory:

If there is a Make.in file, try running:
```
 #  ./configure -prefix=/usr/local  #  make all  
```
If there is an Imake file, try running:
```
 #  xmkmf -a   # make all  
```
If there is a Makefile , try running:
```
  # make all  
```

After the program is built and installed, you might have to do additional configuration. You should consult the man pages or the HOWTOs that come with the software for information on how to proceed.

Tip

With some tar.gz files that include an RPM spec file, you could run the rpm -ta file.tar.gz and the rpm command will build an RPM from that tarball.

To try out this procedure, I downloaded the whichman package, which includes utilities that let you find manual pages by entering keywords. The file I downloaded, whichman-2.2.tar.gz , was placed in a directory that I created called /usr/src/which . I then ran the gunzip and tar commands, using whichman-2.2.tar.gz and whichman-2.2.tar as arguments, respectively.

I changed to the new directory, cd /usr/sw/which/whichman-2.2 . I then listed its contents. The README file contained information about the contents of the package and how to install it. As the README file suggested, I typed make , and then make install . The commands whichman, ftwhich , and ftff were installed in /usr/bin . (At this point, you can check the man page for each component to see what it does.)

The last thing I found in the README file was that a bit of configuration needed to be done. I added a MANPATH variable to my $HOME/.bashrc to identify the location of man pages on my computer to be searched by the whichman utility. The line I added looked like this:

  export MANPATH=/usr/share/man:/usr/man/man1:/usr/X11R6/man:/usr/share/doc/samba-   2.2.3a/docs

In case you are wondering, whichman, ftwhich , and ftff are commands that you can use to search for man pages. They can be used to find several locations of a man page, man pages that are close to the name you enter, or man pages that are located beneath a point in the directory structure, respectively.