After you have the RPM system installed on your platform, the next big step is to create an RPM database for your platform. You can make an empty database with the rpm --initdb command, as shown following:

# mkdir /var/lib/rpm

# rpm --initdb

The first command creates the default directory for the RPM database.

You may need to pass command-line options to specify a non-default location of the RPM database, such as the following:

# rpm --dbpath /location/of/your/rpm/database --initdb

Use a command like this one if you don’t want to place the RPM database in its default location.

In addition, use the –v option to add more verbose output. This is very useful if errors occur. Use the --root option to specify a different root directory for RPM operations. Use the --rcfile option to specify a non-default set of rc files and the --macros option to specify a non-default set of macros.

Cross Reference

Chapter 20, Customizing RPM Behavior covers RPM customization.

Initializing the RPM database creates the necessary structure for an empty database. You can then fill, or populate, the database with packages. In most cases, all you need to do is install packages to populate the RPM database, as each installed package gets added to the database.

Each time you install a package, you populate the RPM database. This works well, as long as you have already installed all the dependencies for the packages you want to install.

On an operating system that is based on RPM, such as Red Hat Linux, all packages (except for some bootstrapping code) are installed with RPM. That means nearly everything on the system is defined in the RPM database. The RPM database then has a full knowledge of what you have installed and can properly handle dependencies. Thus, a failure to find a dependency means that you have not installed the requisite package that provides the needed capability.

On an operating system that is not based on RPM, however, such as Solaris or IRIX, most packages have already been installed by some means other than RPM.. That’s because these operating systems use different native package-management techniques and different package formats.

It is very likely that RPM packages you want to install have dependencies that come from non-RPM packages. For example, the rpm program on Windows depends on the cygwin environment, yet this environment needs to be installed with a Windows setup.exe program, not with the rpm command.

To get around this problem, you need to populate the new RPM database with a package or packages that reflect the current system in order to properly handle dependencies. The main way to do this is to set up a virtual package.

You can get around the problem of pre-existing software by building a virtual package that lists the system libraries@mdinstalled without RPM@mdin an RPM package. This way, the rpm command will find that the dependencies are installed, even if they were not really installed with RPM. You need to do this for all capabilities and system libraries installed outside of RPM control.

To help create such a virtual package, use the vpkg-provides.sh script from the scripts directory. The vpkg-provides.sh script searches a list of directories for shared libraries and interpreters (such as shells). The vpkg-provides.sh script then creates a spec file that lists all the files found, files that are managed outside of RPM. You can use this spec file to create an RPM and install the RPM using the rpm command to populate the RPM database.

The RPM spec file created by the vpkg-provides.sh doesn’t really install any files, as all the files are already installed. Instead it makes a package that claims ownership for all these files so that RPM dependencies can function properly.

The vpkg-provides.sh script accepts three main command-line options: --spec_header, --ignore_dirs, and --no_verify.

The --spec_header option tells the script the name of the RPM spec file it should use as a header for the spec file it will produce. You need to provide the path to the file. For example:

# sh vpkg-provides.sh --spec_header /path/to/spec/file

You need to provide a spec file header to make a complete spec file. This header should contain the Summary, Name, Version, and Release settings, at least. Chapter 9, Working with Spec Files covers these spec file tags.

The --ignore_dirs option tells the vpkg-provides.sh script to ignore certain directories. You need to pass a list of egrep search patterns that identify the directories to ignore. Separate each pattern with a pipe character, |.

Note

The egrep command may not be available on your system. It may be easier to edit the vpkg-provides.sh script and manually specify the directories to ignore.

The --no_verify option tells the vpkg-provides.sh script to skip the step of creating a script to verify checksums of all files in the package.

In addition to these main command-line options, you can also pass the following options to the vpkg-provides.sh script.

The --shlib_dirs option tells the vpkg-provides.sh script the directories to look for shared libraries. Pass a colon-delimited list of directories. For example:

# sh vpkg-provides.sh --spec_header /path/to/spec/file \

--shlib_dirs "/bin:/usr/bin:/sbin:/usr/sbin:/usr/ucb:/usr/bsd"

The --interp_dirs option tells the vpkg-provides.sh script which directories to look in to find interpreters such as sh, bash, perl, wish (Tcl/Tk), and awk. The --interps option tells the vpkg-provides.sh script the names of the interpreter commands. Both these options expect a colon-delimited list.

The --find_provides option tells the vpkg-provides.sh script the name of the find-provides script to use, defaulting to /usr/lib/rpm/find-provides.

The vpkg-provides.sh script defines specific directories to look in for shared libraries and interpreters under various operating systems. You will most likely need to edit this section.

In fact, if you are working with a non-Unix system, or if you experience problems running the vpkg-provides.sh script, you can edit the file to remove the problematic commands. You can also create a new script in a scripting language supported on your system. The vpkg-provides.sh script is a Linux shell script. Linux and Unix systems should be able to run the script, but non-Unix systems likely won’t have the commands and may also not support shell scripts at all. In an effort to be generic, the vpkg-provides.sh script does a lot of work. You can limit this by explicitly specifying directories and commands, for example. And, if all else fails, you can create a virtual package manually (covered in the following section).

When complete, the vpkg-provides.sh script outputs a spec file, using the header you provided, and outputs a set of Provides: lines to specify what the package provides. It then outputs some empty definitions for the prep, build, install, and clean section of the spec file.

For example, you can run the vpkg-provides.sh script with a command like the following:

$ sh ./vpkg-provides.sh --spec_header my_header.spec --find_provides ./find-provides --no_verify

Note

If you run this script as a non-root user, you may get a number of permission errors as the vpkg-provides.sh script searches through system directories.

The script will then output your spec file header along with output like that shown in Listing 20-1.

Listing 20-1: Output from the vpkg-provides.sh script

Provides: /bin/sh

Provides: /bin/csh

Provides: /bin/ksh

Provides: /bin/perl

Provides: /bin/awk

Provides: /bin/nawk

Provides: /bin/oawk

Provides: /usr/bin/sh

Provides: /usr/bin/csh

Provides: /usr/bin/ksh

Provides: /usr/bin/perl

Provides: /usr/bin/awk

Provides: /usr/bin/nawk

Provides: /usr/bin/oawk

Provides: /sbin/sh

Provides: /usr/dt/bin/dtksh

Provides: /usr/xpg4/bin/sh

Provides: /usr/xpg4/bin/awk

%prep

# nothing to do

%build

# nothing to do

%install

# nothing to do

%clean

# nothing to do

%files

# no files in a virtual package

The vpkg-provides.sh script also outputs a package description that explains how the package was created. This is important so that you know this is a virtual package.

When done, use the rpmbuild command to create an RPM from the generated spec file.

Cross Reference

Chapter 8, Creating RPMs: An Overview covers how to run the rpmbuild command, and Chapter 9, Working with Spec Files covers spec files in detail.

Even on Unix-like systems you may experience troubles with the vpkg-provides.sh script. That’s simply because the vpkg-provides.sh script assumes a number of Unix and GNU utilities are available. In most cases, it will work best if you can fix what went wrong and run the vpkg-provides.sh script again.

If all else fails, though, you can create a virtual package spec file manually. Create a spec file starting with the Summary, Name, Version, and Release settings.

Looking at the output shown in Listing 20-1, you can create a Provides: statement for each shared library on your system, and each interpreter, such as shells. Add each statement to your spec file. For example:

Provides: libgen.so

Copy the prep, build, install, and clean section exactly as they are in Listing 20-1. You can now run the rpmbuild command to create a virtual package. Install this package.