<HTML
><HEAD
><TITLE
>Building RPMs</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
REL="HOME"
TITLE="RPM HOWTO"
HREF="index.html"><LINK
REL="PREVIOUS"
TITLE="Now what can I really do with RPM?"
HREF="rpm-do.html"><LINK
REL="NEXT"
TITLE="Building It"
HREF="build-it.html"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>RPM HOWTO: </TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="rpm-do.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="build-it.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="BUILD">6. Building RPMs</H1
><P
> Building RPMs is fairly easy to do, especially if you can get the
software you are trying to package to build on its own. We assume
here that you know how to build software from source. If you don't
you probably shouldn't be starting with this document.
</P
><P
> The basic procedure to build an RPM is as follows:
</P
><P
></P
><UL
><LI
STYLE="list-style-type: disc"
><P
> Get the source code you are building the RPM for to build
on your system.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> Make a patch of any changes you had to make to the sources to get
them to build properly.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> Make a spec file for the package.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> Make sure everything is in its proper place.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> Build the package using RPM.
</P
></LI
></UL
><P
> Under normal operation, RPM builds both binary and source packages.
</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="SPEC-FILE">6.1. The Spec File</H2
><P
> We'll begin with discussion of the spec file. Spec files are required
to build a package. The spec file is a description of the software
along with instructions on how to build it and a file list for all the
binaries that get installed.
</P
><P
> You'll want to name your spec file according to a standard convention.
It should be the package name-dash-version number-dash-release
number-dot-spec. This will ensure that if you install multiple source
RPMs for different versions of the same package that at least the spec
files remain intact.
</P
><P
> Here is a small spec file (eject-2.0.2-1.spec):
</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="PROGRAMLISTING"
>Summary: A program that ejects removable media using software control.
Name: eject
Version: 2.0.2
Release: 3
Copyright: GPL
Group: System Environment/Base
Source: http://metalab.unc.edu/pub/Linux/utils/disk-management/eject-2.0.2.tar.gz
Patch: eject-2.0.2-buildroot.patch
BuildRoot: /var/tmp/%{name}-buildroot
%description
The eject program allows the user to eject removable media
(typically CD-ROMs, floppy disks or Iomega Jaz or Zip disks)
using software control. Eject can also control some multi-
disk CD changers and even some devices' auto-eject features.
Install eject if you'd like to eject removable media using
software control.
%prep
%setup -q
%patch -p1 -b .buildroot
%build
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/bin
mkdir -p $RPM_BUILD_ROOT/usr/man/man1
install -s -m 755 eject $RPM_BUILD_ROOT/usr/bin/eject
install -m 644 eject.1 $RPM_BUILD_ROOT/usr/man/man1/eject.1
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root)
%doc README TODO COPYING ChangeLog
/usr/bin/eject
/usr/man/man1/eject.1
%changelog
* Sun Mar 21 1999 Cristian Gafton <gafton@redhat.com>
- auto rebuild in the new build environment (release 3)
* Wed Feb 24 1999 Preston Brown <pbrown@redhat.com>
- Injected new description and group.
[ Some changelog entries trimmed for brevity. -Editor. ]
</PRE
></FONT
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="HEADER">6.2. The Header</H2
><P
> The header has some standard fields in it that you need to fill in. There
are a few caveats as well. The fields must be filled in as follows:
</P
><P
></P
><UL
><LI
STYLE="list-style-type: disc"
><P
> <EM
>Summary:</EM
> This is a one line description of the
package.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <EM
>Name:</EM
> This must be the name string from the rpm
filename you plan to use.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <EM
>Version:</EM
> This must be the version string from
the rpm filename you plan to use.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <EM
>Release:</EM
> This is the release number for a
package of the same version (ie. if we make a package and find it to
be slightly broken and need to make it again, the next package would
be release number 2).
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <EM
>Copyright:</EM
> This line tells how a package is
copyrighted. You should use something like GPL, BSD, MIT, public
domain, distributable, or commercial.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <EM
>Group:</EM
> This is a group that the package belongs
to in a higher level package tool or the Red Hat installer.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <EM
>Source:</EM
> This line points at the HOME location
of the pristine source file. It is used if you ever want to get the
source again or check for newer versions. Caveat: The filename in
this line MUST match the filename you have on your own system
(ie. don't download the source file and change its name). You can
also specify more than one source file using lines like:
</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="PROGRAMLISTING"
>Source0: blah-0.tar.gz
Source1: blah-1.tar.gz
Source2: fooblah.tar.gz
</PRE
></FONT
></TD
></TR
></TABLE
><P
> These files would go in the <SPAN
CLASS="SYSTEMITEM"
>SOURCES</SPAN
>
directory. (The directory structure is discussed in a later section,
"The Source Directory Tree".)
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <EM
>Patch:</EM
> This is the place you can find the patch
if you need to download it again. Caveat: The filename here must
match the one you use when you make YOUR patch. You may also want
to note that you can have multiple patch files much as you can have
multiple sources. ] You would have something like:
</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="PROGRAMLISTING"
>Patch0: blah-0.patch
Patch1: blah-1.patch
Patch2: fooblah.patch
</PRE
></FONT
></TD
></TR
></TABLE
><P
> These files would go in the <SPAN
CLASS="SYSTEMITEM"
>SOURCES</SPAN
>
directory.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <EM
>Group:</EM
> This line is used to tell high level
installation programs (such as Red Hat's
<SPAN
CLASS="APPLICATION"
>gnorpm</SPAN
>) where to place this particular
program in its hierarchical structure. You can find the latest
description in <SPAN
CLASS="SYSTEMITEM"
>/usr/doc/rpm*/GROUPS</SPAN
>. The
group tree currently looks something like this:
</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="PROGRAMLISTING"
>Amusements/Games
Amusements/Graphics
Applications/Archiving
Applications/Communications
Applications/Databases
Applications/Editors
Applications/Emulators
Applications/Engineering
Applications/File
Applications/Internet
Applications/Multimedia
Applications/Productivity
Applications/Publishing
Applications/System
Applications/Text
Development/Debuggers
Development/Languages
Development/Libraries
Development/System
Development/Tools
Documentation
System Environment/Base
System Environment/Daemons
System Environment/Kernel
System Environment/Libraries
System Environment/Shells
User Interface/Desktops
User Interface/X
User Interface/X Hardware Support
</PRE
></FONT
></TD
></TR
></TABLE
></LI
><LI
STYLE="list-style-type: disc"
><P
> <EM
>BuildRoot:</EM
> This line allows you to specify a
directory as the "root" for building and installing the new
package. You can use this to help test your package before having
it installed on your machine.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <EM
>%description</EM
> It's not really a header item, but
should be described with the rest of the header. You need one
description tag per package and/or subpackage. This is a multi-line
field that should be used to give a comprehensive description of the
package.
</P
></LI
></UL
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PREP">6.3. Prep</H2
><P
> This is the second section in the spec file. It is used to get the
sources ready to build. Here you need to do anything necessary to get
the sources patched and setup like they need to be setup to do a
<B
CLASS="COMMAND"
>make</B
>.
</P
><P
> One thing to note: Each of these sections is really just a place to
execute shell scripts. You could simply make an
<SPAN
CLASS="SYSTEMITEM"
>sh</SPAN
> script and put it after the
<EM
>%prep</EM
> tag to unpack and patch your sources.
We have made macros to aid in this, however.
</P
><P
> The first of these macros is the <EM
>%setup</EM
>
macro. In its simplest form (no command line options), it simply
unpacks the sources and <B
CLASS="COMMAND"
>cd</B
>'s into the source
directory. It also takes the following options:
</P
><P
></P
><UL
><LI
STYLE="list-style-type: disc"
><P
> <TT
CLASS="PARAMETER"
><I
>-n name</I
></TT
> will set the name of
the build directory to the listed <EM
>name</EM
>. The
default is <EM
>$NAME-$VERSION</EM
>. Other
possibilities include <EM
>$NAME</EM
>,
<EM
>${NAME}${VERSION}</EM
>, or whatever
the main tar file uses. (Please note that these "$"
variables are <EM
>not</EM
> real variables available
within the spec file. They are really just used here in place of a
sample name. You need to use the real name and version in your
package, not a variable.)
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <TT
CLASS="PARAMETER"
><I
>-c</I
></TT
> will create and cd to the
named directory <EM
>before</EM
> doing the untar.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <TT
CLASS="PARAMETER"
><I
>-b #</I
></TT
> will untar Source#
<EM
>before</EM
> <B
CLASS="COMMAND"
>cd</B
>'ing into the
directory (and this makes no sense with <TT
CLASS="PARAMETER"
><I
>-c</I
></TT
> so don't do it). This is only useful
with multiple source files.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <TT
CLASS="PARAMETER"
><I
>-a #</I
></TT
> will untar Source#
<EM
>after</EM
> cd'ing into the directory.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <TT
CLASS="PARAMETER"
><I
>-T</I
></TT
> This option overrides the
default action of untarring the Source and requires a <TT
CLASS="PARAMETER"
><I
>-b 0</I
></TT
> or <TT
CLASS="PARAMETER"
><I
>-a
0</I
></TT
> to get the main source file untarred. You need this
when there are secondary sources.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <TT
CLASS="PARAMETER"
><I
>-D</I
></TT
> Do <EM
>not</EM
>
delete the directory before unpacking. This is only useful where
you have more than one setup macro. It should
<EM
>only</EM
> be used in setup macros
<EM
>after</EM
> the first one (but never in the first
one).
</P
></LI
></UL
><P
> The next of the available macros is the <EM
>%patch</EM
>
macro. This macro helps automate the process of applying patches to the
sources. It takes several options, listed below:
</P
><P
></P
><UL
><LI
STYLE="list-style-type: disc"
><P
> <EM
>#</EM
> will apply Patch# as the patch file.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <TT
CLASS="PARAMETER"
><I
>-p #</I
></TT
> specifies the number
of directories to strip for the patch(1) command.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <TT
CLASS="PARAMETER"
><I
>-P</I
></TT
> The default action is to
apply <B
CLASS="COMMAND"
>Patch</B
> (or <B
CLASS="COMMAND"
>Patch0</B
>). This
flag inhibits the default action and will require a <TT
CLASS="PARAMETER"
><I
>0</I
></TT
> to get the main source file untarred.
This option is useful in a second (or later)
<B
CLASS="COMMAND"
>%patch</B
> macro that required a different
number than the first macro.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> You can also do <B
CLASS="COMMAND"
>%patch#</B
> instead
of doing the real command: <B
CLASS="COMMAND"
>%patch # -P</B
>
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <TT
CLASS="PARAMETER"
><I
>-b extension</I
></TT
> will save
originals as <TT
CLASS="FILENAME"
>filename.extension</TT
> before
patching.
</P
></LI
></UL
><P
> That should be all the macros you need. After you have those right, you
can also do any other setup you need to do via
<SPAN
CLASS="SYSTEMITEM"
>sh</SPAN
> type scripting. Anything you include up
until the <EM
>%build</EM
> macro (discussed in the
next section) is executed via <SPAN
CLASS="SYSTEMITEM"
>sh</SPAN
>. Look at the
example above for the types of things you might want to do here.
</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="BUILD-SPEC">6.4. Build</H2
><P
> There aren't really any macros for this section. You should just put
any commands here that you would need to use to build the software once
you had untarred the source, patched it, and cd'ed into the directory.
This is just another set of commands passed to
<SPAN
CLASS="SYSTEMITEM"
>sh</SPAN
>, so any legal <SPAN
CLASS="SYSTEMITEM"
>sh</SPAN
>
commands can go here (including comments).
</P
><DIV
CLASS="IMPORTANT"
><P
></P
><TABLE
CLASS="IMPORTANT"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/important.gif"
HSPACE="5"
ALT="Important"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
> Your current working directory is reset in each of these sections to
the toplevel of the source directory, so keep that in mind. You can
<B
CLASS="COMMAND"
>cd</B
> into subdirectories if necessary.
</P
></TD
></TR
></TABLE
></DIV
><P
> The variable <TT
CLASS="VARNAME"
>RPM_OPT_FLAGS</TT
> is set using values in
<SPAN
CLASS="SYSTEMITEM"
>/usr/lib/rpm/rpmrc</SPAN
>. Look there to make sure
you are using values appropriate for your system (in most cases you
are). Or simply don't use this variable in your spec file. It is
optional.
</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="INSTALL">6.5. Install</H2
><P
> There aren't really any macros here, either. You basically just want to
put whatever commands here that are necessary to install. If you have
<B
CLASS="COMMAND"
>make install</B
> available to you in the package you are
building, put that here. If not, you can either patch the makefile for
a <B
CLASS="COMMAND"
>make install</B
> and just do a <B
CLASS="COMMAND"
>make
install</B
> here, or you can hand install them here with
<SPAN
CLASS="SYSTEMITEM"
>sh</SPAN
> commands. You can consider your current
directory to be the toplevel of the source directory.
</P
><P
> The variable <TT
CLASS="VARNAME"
>RPM_BUILD_ROOT</TT
> is available to tell you
the path set as the <EM
>Buildroot:</EM
> in the header.
Using build roots are optional but are highly recommended because they
keep you from cluttering your system with software that isn't in your
RPM database (building an RPM doesn't touch your database...you must go
install the binary RPM you just built to do that).
</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="CLEANING">6.6. Cleaning your system</H2
><P
> It's a good idea to always make sure there is a clean build root before
building a package a second time on a system. The
<EM
>%clean</EM
> macro will help with that. Simply
put the proper commands there to blow away a former build root. Anal,
err, careful folks may want to test that
<TT
CLASS="VARNAME"
>RPM_BUILD_ROOT</TT
> wasn't set to
<SPAN
CLASS="SYSTEMITEM"
>/</SPAN
> before doing something this volatile.
</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="SCRIPTS">6.7. Optional pre and post Install/Uninstall Scripts</H2
><P
> You can put scripts in that get run before and after the installation
and uninstallation of binary packages. A main reason for this is to do
things like run <B
CLASS="COMMAND"
>ldconfig</B
> after installing or
removing packages that contain shared libraries. The macros for each of
the scripts is as follows:
</P
><P
></P
><UL
><LI
STYLE="list-style-type: disc"
><P
> <SPAN
CLASS="SYSTEMITEM"
>%pre</SPAN
> is the macro to do pre-install
scripts.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <SPAN
CLASS="SYSTEMITEM"
>%post</SPAN
> is the macro to do
post-install scripts.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <SPAN
CLASS="SYSTEMITEM"
>%preun</SPAN
> is the macro to do
pre-uninstall scripts.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <SPAN
CLASS="SYSTEMITEM"
>%postun</SPAN
> is the macro to do
post-uninstall scripts.
</P
></LI
></UL
><P
> The contents of these sections should just be any
<SPAN
CLASS="SYSTEMITEM"
>sh</SPAN
> style script, though you do
<EM
>not</EM
> need the
<SPAN
CLASS="SYSTEMITEM"
>#!/bin/sh</SPAN
>.
</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="FILES">6.8. Files</H2
><P
> This is the section where you <EM
>must</EM
> list the files
for the binary package. RPM has no way to know what binaries get
installed as a result of <B
CLASS="COMMAND"
>make install</B
>. There is
<EM
>NO</EM
> way to do this. Some have suggested doing a
<B
CLASS="COMMAND"
>find</B
> before and after the package install. With a
multiuser system, this is unacceptable as other files may be created
during a package building process that have nothing to do with the
package itself.
</P
><P
> There are some macros available to do some special things as well. They
are listed and described here:
</P
><P
></P
><UL
><LI
STYLE="list-style-type: disc"
><P
> <SPAN
CLASS="SYSTEMITEM"
>%doc</SPAN
> is used to mark documentation
in the source package that you want installed in a binary install.
The documents will be installed in
<SPAN
CLASS="SYSTEMITEM"
>/usr/doc/$NAME-$VERSION-$RELEASE</SPAN
>.
You can list multiple documents on the command line with this macro,
or you can list them all separately using a macro for each of them.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <SPAN
CLASS="SYSTEMITEM"
>%config</SPAN
> is used to mark
configuration files in a package. This includes files like
sendmail.cf, passwd, etc. If you later uninstall a package
containing config files, any unchanged files will be removed and any
changed files will get moved to their old name with a
<SPAN
CLASS="SYSTEMITEM"
>.rpmsave</SPAN
> appended to the filename. You can
list multiple files with this macro as well.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <SPAN
CLASS="SYSTEMITEM"
>%dir</SPAN
> marks a single directory in a
file list to be included as being owned by a package. By default,
if you list a directory name <EM
>WITHOUT</EM
> a
<SPAN
CLASS="SYSTEMITEM"
>%dir</SPAN
> macro,
<EM
>EVERYTHING</EM
> in that directory is included in the
file list and later installed as part of that package.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <SPAN
CLASS="SYSTEMITEM"
>%defattr</SPAN
> allows you to set default
attributes for files listed after the defattr declaration. The
attributes are listed in the form <EM
>(mode, owner,
group)</EM
> where the mode is the octal number representing
the bit pattern for the new permissions (like
<B
CLASS="COMMAND"
>chmod</B
> would use), owner is the username of the
owner, and group is the group you would like assigned. You may
leave any field to the installed default by simply placing a
<EM
>-</EM
> in its place, as was done in the mode field
for the example package.
</P
></LI
><LI
STYLE="list-style-type: disc"
><P
> <SPAN
CLASS="SYSTEMITEM"
>%files -f <filename></SPAN
> will
allow you to list your files in some arbitrary file within the build
directory of the sources. This is nice in cases where you have a
package that can build it's own filelist. You then just include
that filelist here and you don't have to specifically list the
files.
</P
></LI
></UL
><P
> The <EM
>biggest caveat</EM
> in the file list is listing
directories. If you list <SPAN
CLASS="SYSTEMITEM"
>/usr/bin</SPAN
> by accident,
your binary package will contain <EM
>every</EM
> file in
<SPAN
CLASS="SYSTEMITEM"
>/usr/bin</SPAN
> on your system.
</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="CHANGELOG">6.9. Changelog</H2
><P
> This is a log of what changes occurred when the package is updated. If
you are modifying an existing RPM it is a good idea to list what changes
you made here.
</P
><P
> The format is simple. Start each new entry with a line with a *
followed by the date, your name, and your email address. The date
should appear in the same format that is output by:
</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="PROGRAMLISTING"
> date +"%a %b %d %Y"
</PRE
></FONT
></TD
></TR
></TABLE
><P
> The rest of the section is a free text field, but should be organized
in some coherent manner.
</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="rpm-do.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="build-it.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Now what can I really do with RPM?</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
> </TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Building It</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
