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