Chapter 20

RPM on Other Operating Systems

Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/).

In This Chapter

*	Running RPM on other operating systems

*	Bootstrapping RPM on other operating systems

*	Setting up the RPM environment

*	Creating non-Linux RPMs

*	Setting up an RPM build environment

*	Cross-building packages

RPM was originally designed on Linux and for most of its life has been a Linux-centric package management system. But most Linux programs are portable to most versions of Unix or Unix -like operating systems. Linux is, after all, a Unix-workalike operating system.

The RPM system is no exception. It has been ported to a number of operating systems, including quite a few Unix variants. The source code is freely available, so you can port RPM to other systems as well.

This chapter covers running RPM on non-Linux operating systems, including getting the RPM system in the first place, bootstrapping an RPM environment, and creating packages for other operating systems.

The first step is to get RPM for your system, or port RPM if it isn’t already available.

Running RPM on Other Operating Systems

The RPM system, made up of mostly the rpm and rpmbuild commands, have been ported to a number of operating systems. There is nothing stopping you from running the RPM system on other platforms.

Other operating systems have their own native package management software. You may prefer the way RPM works, or merely want to standardize on RPM across all platforms you manage. There will always be a few issues, however, when running RPM on other operating systems. For example, operating system patches and updates are likely to be distributed in the operating system’s native package management format, not RPM. Many applications will be updated also using the system’s native package management format.

You will need to always keep in mind that there are two package management schemes in use: RPM and the native one. This issue has not stopped a great many people from using RPM on other systems, though, as shown by the list of platforms RPM has been ported to (see Table 20-1 for the list).

On the plus side, package management has always been one of the main areas where versions of Linux, Unix, and other operating systems differ, sometimes quite a lot. By using RPM, you can transfer your knowledge of package management from one system to another, saving valuable time and hassles. You will be able to update systems in the same manner, a big plus if you manage a diverse set of systems.

Another reason to use RPM on other operating systems is that in most cases, RPM provides far more capabilities than the native package management software. Following the RPM philosophy, each package can be separately verified, checked, and updated. Each package lists the other packages it depends on, and also lists the capabilities it provides. You can automate the installation and upgrade processes with RPM. You can also perform a lot of version and signature comparisons. All of this leads to a more secure, more robust system.

Many operating systems don’t include these capabilities in the native package management software. This is why many users run RPM on other operating systems.

Cross Reference

See Chapter 2 for more on the philosophy behind RPM.

If you decide to use RPM on a non-Linux system, the first step is getting RPM for your system, if it is available.

Getting RPM for your system

The first step to using RPM on non-Linux platforms is getting the RPM system for your platform. In most cases, this is a relatively easy step, as RPM has been ported to a great many platforms, as listed on the main RPM Web site.

Cross Reference

Links to RPM versions for various platforms are listed at www.rpm.org/platforms/.

Go to this site and download the versions for the platforms you need. Table 20-1 lists the platforms RPM has been ported to, as reported by the RPM site.

Table 20-1 Available Platforms for RPM

Platform	Notes
AIX	
AmigaOS	With GeekGadgets
BeOS	With GeekGadgets
FreeBSD	
HP-UX	10.20+, 9.04
IRIX	
Linux	Multiple platforms including Alpha, Intel, Motorola 68000, SGI MIPS, PowerPC, and SPARC
LynxOS	
MachTen	
MacOS X	
Mint	
NCS System V	
NetBSD	
OS/2	
OSF/1	3.2+
SCO OpenServer	5.0.2+
Sinix	
Solaris	Solaris for SPARC 2.4 and 8+, Solaris for Intel
SunOS 4.1.3	
Windows	Under Cygwin

Note that RPM has likely been ported to even more platforms. These are just the ones reported to the rpm.org site.

Note

If you fix a bug in RPM on a non-Linux system, or if you port RPM to a new system, please report this to the rpm.org site maintainers, as well as make your work available for others. You never know, but someone else may fix a problem you’re facing.

If Table 20-1 does not cover the platforms you need, you must compile and bootstrap the RPM environment for your platforms, as covered in the "Bootstrapping RPM on Other Operating Systems" section, following.

Note

Don’t expect to find RPMs of the RPM system for these other platforms. If you did, there would be no way to install RPM. Instead, you’ll find RPM packaged in a variety of formats, typically using a native bundling format for a given system, or at least a supported format. Compressed tar files are very common. RPM for IRIX systems come in IRIX tardist format.

If RPM is available for your system, download the package and follow any installation instructions that come with the package. For example, RPM for Solaris 8 requires the libiconv library, as well as the Solaris packages SUNWzlib and SUNWbzip. You must install these packages prior to installing RPM.

Each operating system will have similar requirements. Windows systems have a few extra requirements due to the fact that Windows is very different from Linux or Unix-like systems.

Running RPM on Windows

The version of RPM for Windows requires cygwin, originally the Cygnus port of many Unix tools to Windows. Now part of Red Hat, you can download the cygwin environment from the main cygwin site.

Cross Reference

Download cygwin from www.cygwin.com.

You can download a setup.exe program to install the environment on Windows. After installation, you can download the RPM system for Windows.

After you have RPM installed, you can set up your RPM system. If RPM wasn’t already ported to your operating systems, however, you will need to bootstrap RPM on your platforms.

Bootstrapping RPM On Other Operating Systems

If you cannot find a version of RPM that has been ported to your platform, you can port it yourself. The RPM system usually isn’t that hard to port to any platform that can appear like Unix or Linux systems, such as any platform that supports POSIX system calls or something like these system calls.

Don’t be dismayed by the sheer size of the RPM package. Much of the RPM system was carefully designed to run across multiple platforms, so file access is abstracted to special portability routines. For example, RPM has been ported to both AmigaOS and BeOS, two non-Unix operating systems.

Downloading the RPM software

To bootstrap RPM on another operating system, download the RPM source code from the main RPM site.

Cross Reference

You can download the RPM source code from ftp://ftp.rpm.org/pub/rpm/dist/.

Note that you probably do not want to download an RPM of the sources, since your platform won’t have RPM available. In most cases, you’ll want to download a tarred compressed archive, such as rpm-4.1.tar.gz for RPM version 4.1.

Extracting the software

If the system you plan to port RPM doesn’t have the tar and gzip commands available, or something that supports these formats, then you need to find a way to extract the software.

Note

Programs such as WinZip on Windows support extracting .tar.gz files. Your platform may have a similar program.

One way is to port the gzip and tar commands to your platform.

Cross Reference

You can download the sources for tar and gzip from www.gnu.org.

Another way is to extract the sources on a platform with these commands available, such as a Linux platform. Then, create a file using a format supported by your operating system and transfer the files to the other system.

Once you have the RPM source code available on your target system, and all the files are extracted, you are ready to start porting. The first step is really simple: read.

Reading the INSTALL file

In the main RPM source directory, you will see two very important files: README and INSTALL. Read them both. (You would be surprised at how many times people need to be told this.)

Of the two, the INSTALL file has much more detailed information on installing RPM on a new system. The INSTALL file describes the libraries required by RPM, provides tips on compiling RPM, and describes some of the set up work necessary after compiling the RPM system.

Some of the hardest parts of the RPM system to port, though, may be in the database, compression, and encryption calls, used as libraries by the RPM system.

Libraries required by RPM

Rather than invent everything from scratch, the RPM system makes use of a number of libraries, including those listed in Table 20-2.

Table 20-2 Libraries used by RPM

Library	Purpose
Berkeley DB	RPM database, using db1 and db3
bzip2	Compression
gettext	International text lookup
gpg	For digital signatures
gzip	Compression
popt	Processing command-line options
zlib	Compression

Read through the INSTALL file to find out where you can download versions of these libraries. You may find that each library has its own set of dependencies, all of which you need to port to your target platform.

Tools for building RPM

In addition to the libraries listed in Table 20-2, RPM requires a number of GNU utilities for building RPM, including those listed in Table 20-3.

Table 20-3 Tools used to build RPM

Tool	Usage
Autoconf	Builds configure scripts
Automake	Used with autoconf
GNU make	Used to control building the sources
Libtool	Used by the autogen.sh script

In addition to all this, RPM works best with the GNU C compiler, GCC, and the GNU make program, gnumake, or simply gmake.

Cross Reference

The source code for all the GNU tools is available at www.gnu.org.

Compiling RPM

After downloading the RPM sources, extracting all the files and installing all the prerequisite libraries, you are ready to start compiling RPM.

RPM includes quite a few subsystems, such as popt for parsing command-line options. Each of these subsystems requires some configuration. Most of this configuration is automated through the use of the autogen.sh script and the autoconf/automake tool used to create configure scripts.

The autogen.sh script is a Bourne shell script that checks for specific versions of necessary tools and libraries. After checking dependencies, the autogen.sh script calls different autogen.sh scripts in the beecrypt, libelf, popt, and zlib directories. When done with that task, the autogen.sh script calls configure.

Pass a command-line option of --noconfigure to disable the call to configure.

Edit the autogen.sh script if you are using different versions of the necessary tools. The autogen.sh script is coded to require the specific versions of these tools as were used originally to build the RPM package. In addition, your system may have libraries stored in different locations than those expected by the autogen.sh, so it's a good idea to edit this script and verify all the assumptions.

Note

One really big assumption in this script is that you have a Unix-like operating system. If not, you will need to determine how to set up the Makefiles manually. This requires a lot of trial and error while you edit the Makefiles and then see if you can build the software. Fix each problem that arises and try again.

When you are done with the autogen.sh script, you can use the following basic commands to create system-specific Makefiles, compile RPM and install the commands:

$ ./configure

$ make

$ make install

The configure script takes the Makefile.in files and uses these files as templates to create custom versions of Makefile.in files, tuned to your system. (The automake system starts with a Makefile.am file, creates an expanded Makefile.in file, and finally results in a Makefile tuned to your system.) If all else fails, you can copy each Makefile.in file to Makefile and then edit the Makefile to make one that will work on your system.

Cross Reference

See the GNU site, at www.gnu.org, for more on the autoconf and automake tools.

If the make install step fails, you can manually copy the RPM executables and scripts to a directory for system commands.

Handling problems

If RPM fails to compile or install, you can still work around many issues. The key is to find out what went wrong, fix the problem, and try again. You may go through this loop many times before RPM successfully compiles and installs.

Most problems can be solved by changing the configuration settings. If possible, change the inputs to the configure command to specify C compiler options, and so on, that you discover you need. You can then run the basic commands to build RPM again, but with any special options you discovered are necessary:

$ ./configure –any_options_set_here

$ make

$ make install

If you take this approach, you avoid having to edit a number of Makefiles (one in each source code subdirectory) by hand. You also have an easier time of switching to different command-line options as you determine more solutions to the compilation problems.

If this won’t work, though, you can edit the Makefile.am file or the generated Makefile directly to add whatever settings are needed. For example, you may need to specify additional directories for libraries, or some C compiler compatibility option.

As you discover problems, remember you are not alone in porting RPM. Check the RPM mailing list, where the question of getting RPM going on other platforms comes up frequently.

Cross Reference

For details on viewing the RPM mailing list archives and signing up for the list, see www.rpm.org/mailing_list/.

Setting Up the RPM System

Once you have RPM available on your platform, you need to set up the RPM system. This includes setting up the RPM database and creating an RPM environment.

Setting up the RPM database

After you have the RPM system available on your platform, you need to set up the RPM database. This usually involves two steps:

*	Initializing an empty RPM database

*	Populating the database with packages, especially for dependencies

Both steps are necessary.

Initializing an Empty RPM Database

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 21 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.

Handling Dependencies for Packages Installed Without RPM

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.

Setting 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 10 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 sections 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 9 covers how to run the rpmbuild command, and Chapter 10 covers spec files in detail.

Creating a Virtual Package Manually

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 sections exactly as they are in Listing 20-1. You can now run the rpmbuild command to create a virtual package. Install this package.

Creating the RPM environment

The RPM environment is made up of a large number of RPM settings and macro definitions. Run the rpm --showrc command to see the current environment settings on Linux:

$ rpm –showrc

ARCHITECTURE AND OS:

build arch : i386

compatible build archs: i686 i586 i486 i386 noarch

build os : Linux

compatible build os's : Linux

install arch : i686

install os : Linux

compatible archs : i686 i586 i486 i386 noarch

compatible os's : Linux

RPMRC VALUES:

macrofiles : /usr/lib/rpm/macros:/usr/lib/rpm/i686-linux/macros:/etc/

rpm/macros.specspo:/etc/rpm/macros.db1:/etc/rpm/macros.cdb:/etc/rpm/macros:/etc/

rpm/i686-linux/macros:~/.rpmmacros

optflags : -O2 -march=i686

This output was truncated for space. As you can see, there are a lot of expected settings. You need to set up these same settings and macros, but with the proper values for the new system on which you are running RPM.

The files rpmrc.in and macros.in serve as the default templates used to create the rc and macro settings, respectively. These files are modified by the configure script to include values specific to the local operating system. You can edit these files as needed for your system, prior to installing RPM. That is, edit these files between calling the make command and the make install command.

Cross Reference

Chapter 21 covers how to customize the RPM settings and macros, along with the popt aliases.

The INSTALL file in the RPM sources also describes some modifications you may want to make to the macros.

Creating Non-Linux RPMS

Once you have RPM set up on a system, you should be able to create RPMs using the rpmbuild command on that system.

Warning

Do not build RPM packages logged in as a root or Administrator user. If something goes wrong, rpmbuild could destroy files in your system. Remember that spec files can define a number of commands and shell scripts. Any of these could have an error that could cause major damage when run as a root user.

Before building RPMs with the rpmbuild command, though, you may want to customize the build environment to better reflect your system. You may also find it is too difficult to build most RPMs on the non-Linux system and instead focus on cross-building packages, should the rpmbuild command not work on the target systems.

This section covers topics related to building RPMs on or for non-Linux systems.

Setting up a build environment

In RPM terms, your build environment consists of the directories where you build RPMs, as well as the rc and macro settings that define all of the variables in an RPM-based system. To set up your build environment, you need to ensure that all the rc and macro settings reflect the true environment on your non-Linux system.

The rpm --showrc command, discussed previously in the "Creating the RPM Environment" section, lists the settings for your system. You can use this command to verify all the settings.

You may want to change some settings, such as the top directory where RPMs are built. By default, this setting is something like the following:

_topdir %{_usrsrc}/redhat

Cross Reference

See Chapter 21 for more on how to customize the rc and macro settings.

In most cases the _topdir setting on Red Hat Linux systems map to the /usr/src/redhat directory. Your system may not even have a /usr/src directory. Also you may not want to build RPMs in a redhat directory, which may cause confusion if you are building on a non-Red Hat Linux system.

Cross Reference

See Chapter 19 for more information on setting up a build environment for RPMs. Chapter 19 focuses on other Linux systems, but many of the same techniques apply.

With a build environment set up, you should be able to create RPMs with the rpmbuild command. If this doesn’t work, or is too difficult, then you can try cross-building packages.

Cross-building packages

You may find that it is too difficult to create RPMs on a given platform. It may be easier to build the RPMs on another platform, such as a Linux system, as if it were on the target platform. This is called cross-building packages, since you are building a package on one system specifically designed for another.

In most cases, the target platform is quite different from the system where you cross-build packages. Otherwise, you would likely just build the RPMs on the target platform.

The key issues with cross-building are the following:

*	You must compile any executables with a cross compiler for the proper target platform.

*	You must set the target platform in the RPMs you build.

*	You must manage dependencies, and likely need to turn off the automatic generation of dependencies.

Note

Setting up a cross-building environment is oftentimes more work than it is worth. If you can compile applications and build packages on the target system, do that. The cross-building option should be used only if you really cannot build packages on the target system. For example, many handheld or small-format computers lack the processor performance or memory to compile applications. These are good candidates for cross-building.

To compile executables for another platform, especially a platform with a different processor architecture, you need a cross compiler. A cross compiler runs on one system and produces executables for another.

Note

Cross compilers are heavily used when working with embedded and small device systems. The embedded system may not have the processor power to compile applications, or it may simply be inconvenient to compile applications on the embedded system.

The Linux gcc compiler can act as a cross compiler if you install the right gcc add-on packages. See the GNU site for more on the gcc compiler.

Cross Reference

You can download GCC and other GNU software from www.gnu.org.

In addition to compiling for the target platform, you need to ensure that the RPM is marked as being for the target architecture. If not, the rpm command will fail when trying to install the RPM on the target system.

You can set the target architecture with the --target option to the rpmbuild command. For example:

rpmbuild –bi --target arm-sharp-linux

This specifies a target CPU architecture of ARM, the vendor Sharp (which just happens to make an ARM-based Linux device) and the operating system of Linux. The basic format is:

cpu-vendor-os

Cross Reference

See Chapter 12 for more on using the --target option to the rpmbuild command.

You must also turn off or correct any automatically generated dependencies in RPMs you build for other platforms. That is, any dependencies based on the operating system or architecture of the system you are cross-building on will likely not be found, or be found in a different location or format, on the target platform.

This is where the handy RPM feature of automatically building the dependencies does not work to your advantage. You can turn off this feature, however.

Cross Reference

See Chapter 19 for information on how to turn off the automatic generation of dependencies.

You should turn off the automatically building of dependencies for any packages you cross build.

Using these techniques, you can build packages on one system for use on another, very different system. Due to the difficulties, you should only go this route if it becomes too difficult to use the rpmbuild command on the target systems.

Summary

With its superior package-management capabilities, especially for automated installations and upgrades, you may want to use RPM on non-Linux platforms. As the experience of many developers has shown, you can indeed use RPM on non-Linux platforms.

The rpm.org site maintains a listing of operating systems where developers have ported RPM. If you are lucky, you can download RPM for your operating system and start working right away. If you are not lucky, you will need to port RPM to your target system.

If RPM has been ported to your architecture, download the package and follow the installation instructions. If RPM has not been ported to your architecture, download the RPM sources and all prerequisite libraries. You may need to port each library to your architecture before you can even begin to port RPM.

The RPM sources use a configured build process that also requires some prerequisite tools. You need to get or port these to your architecture as well. Whew.

Once everything is in place, you can start the port of RPM. In many cases, you just need to figure out how to get RPM to compile and everything will fall into place. In other cases, you will need to work on each RPM subsystem to get it to build and run.

After you have RPM for your system, you need to initialize the RPM database with the rpm --initdb command. You can then start to populate your RPM database. Because a large number of libraries have already been installed on your system, you may need to create a virtual package that claims to provide these files. Installing such a virtual package will allow you to install other RPMs that may be dependent on system libraries.

Much of porting RPM to another platform depends on the RPM environment and how you need to customize that environment. The next chapter shows how to customize your RPM environment, on Linux or on other operating systems.

Chapter 20

Chris Ricker

2003-01-25T10:22:00

Eric Foster-Johnson