3 To build RPM you will need several other packages:
4 --------------------------------------------------
7 The zlib library for compression support available from
8 http://www.cdrom.com/pub/infozip/zlib/
10 The berkeley db library db.1.85, or db.2* (currently the latest is
11 db-2.6.4) with compatibility mode for db.1.85 defined. The developers
12 of RPM did not upgrade RPM to use the current version of libdb because
13 they are uncomfortable with changes in the softwares license. Now db2
14 has a special exception license within glibc-2.1 so whatever license
15 discomfort there is/was is quickly becoming moot. The remaining issue
16 is that the db_185 compatibility does not work in glibc-2.1. This is
18 http://www.sleepycat.com/download.html.
20 The instructions for building db-2.6.4:
23 ../dist/configure --enable-compat185
28 It may be desired to install bzip2 and gzip so that RPM can use these
29 formats. Gzip, is necessary to build packages that contain compressed
30 tar balls, these are quite common on the Internet.
31 These are availible from
32 http://www.digistar.com/bzip2/index.html
35 If National Language Support (NLS) is desired
36 you will need gnu gettext available from
39 If you need support of RPM 1.x databases, which are in an old RPM
40 format. You will need the GNU db library gdbm to build the rpmconvert
41 binary. This is availible from :
44 For best results you should compile with GCC and GNU Make. Users have
45 reported difficulty with other build tools. available from
52 If your libraries are in a standard place you will need to change
53 the configure environment.
56 LIBS='-L/opt/libz/ -L/opt/BerkeleyDB/lib/' \
57 CPPFLAGS='-I/opt/libz/ -I/opt/BerkeleyDB/include' \
61 now build the system with:
65 if you wish to make a tarfile of the binaries so that you may easily
66 install on other machines (ed note: what about putting gzip and bzip2
67 in the tar, modifying the /etc/rpmrc?):
71 when installing do not forget to init the database (rpm --initdb)
75 Non Linux Configuration Issues:
76 ------------------------------
82 Under Red Hat Linux all libraries (in fact all files distributed with
83 the OS) are under RPM control and this section is not an issue.
85 RPM will need to be informed of all the dependencies which were
86 satisfied before RPM was installed. Typically this only refers to
87 libraries that are installed by the OS, but may include other
88 libraries and packages which are availible at the time RPM is
89 installed and will not under RPM control. Another common example of
90 libraries which may need dependency provisions are precompiled
91 libraries which are installed by the OS package manager during system
92 build time. The list of dependencies you will wish to load into RPM
93 will depend on exactly how you bootstrap RPM onto your system and what
94 parts of the sytem you put into packages as well as on the specific OS
97 You should satisfy dependencies for all shells and interpreters. A
98 reasonable list of OS installed shells can be generated with:
102 You should satisfy dependencies for all system libraries. For each of
103 the system library directories you should run
105 echo * | find-provides.sh
107 (On Linux a list of system library directories can be found in
108 /etc/ld.so.conf, other OS require an experienced system administrator
109 to know where the libraries are.)
112 You may add as many "provides: " lines as you like to /etc/rpmrc/ but
113 they can not be continued. Each line is limited to 8K bytes. Here is
114 a example (truncated) of the provides lines used by one user of
117 provides: /bin/sh /usr/bin/ksh /usr/bin/csh
118 provides: libc.so.osf.1 libm.so.osf.1 libcurses.so.xpg4 libdb.so.osf.1
119 provides: libX11.so libXaw.so.6.0 libXext.so libXm.so.motif1.2 libXmu.so
120 provides: libdnet_stub.so.osf.1 libsecurity.so.osf.1 libpthread.so.osf.1
121 provides: libexc.so.osf.1 libmach.so.osf.1 libdps.so libdpstk.so
128 If you plan on packaging for more then one OS you may want to edit
129 /etc/rpmrc and change the line which has rpmfilename to something
130 which include both the %{OS} and %{ARCH}. This will cause the name of
131 the generated rpm files to the operating system name as well as the
132 architecture which the rpm runs under. The line to change looks like:
134 > rpmfilename: %{ARCH}/%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm
136 you may wish to include both the %{OS} and %{ARCH} in the final base
137 name, so that it's easier to distinguish between what package is
138 appropriate for a particular arch-os-version combo. We suggest
140 > rpmfilename: %{ARCH}/%{NAME}-%{VERSION}-%{RELEASE}.%{OS}-%{ARCH}.rpm
142 There is no %{OS_VERSION} tag, so if you need to also distinguish between
143 RPMs for certain versions of the OS, you can hard-code the version in
144 the rpmrc on the build machine, so that .rpm files are generated with
145 the version as part of the filename.
147 For example when one user builds RPMs for Digital Unix 4.0b and 4.0d,
148 optimization is important and he will build one set of RPMs for the
149 EV4 processor and another set for the EV56 processor. He specifies
150 both the OS version (if it's important, as it is for a few packages)
151 and the processor version by default by setting a special rpmfilename:
152 on the particular build machine.
154 The "rpmfilename: "tag on one machine (Digital Unix 4.0d, EV56 PWS 433)
157 rpmfilename: %{OS}/4.0d/%{ARCH}/%{NAME}-%{VERSION}-%{RELEASE}.%{OS}-%{ARCH}-ev56.rpm
159 For package `foo-1.1', at build time that would translate into:
161 osf1/4.0d/alpha/foo-1.1-1.osf1-alphaev56.rpm