INSTALL

   1 To build RPM you will need several other packages:
   2 --------------------------------------------------
   3
   4 The zlib library for compression support. You might also need/want
   5 the zip executable for java jar dependency analysis. All available from
   6     http://www.gzip.org/zlib/
   7
   8 The libmagic (aka file) library for file type detection (used by rpmbuild).
   9 The source for the file utility + library is available from
  10     ftp://ftp.astron.com/pub/file/
  11
  12 The NSS library for encryption. This is available from
  13     http://www.mozilla.org/projects/security/pki/nss/
  14
  15 The Berkeley DB >= 4.3.x (4.5.x or newer recommended) is required for the
  16 default database backend. BDB can be downloaded from
  17 http://www.oracle.com/technology/software/products/berkeley-db/index.html
  18
  19 RPM supports two different ways to include it, both methods have their
  20 distinct advantages and disadvantages:
  21
  22 1) Building and using an internal copy of BDB
  23
  24    This is the "safe" way: upgrades to system BDB can not affect your
  25    rpmdb integrity and you have full control over how BDB is configured.
  26    On the other hand, any updates (security or bugfix) to BDB will require
  27    rebuilding RPM.
  28
  29    To use this method, download a recent version of BDB from the URL above,
  30    expand the tarball into rpm source directory root and create "db" symlink
  31    to it, eg:
  32    $ wget http://download.oracle.com/berkeley-db/db-4.5.20.tar.gz
  33    $ tar xzf db-4.5.20.tar.gz
  34    $ ln -s db-4.5.20 db
  35    $ ./configure [other options...]
  36
  37 2) Linking to external (system) BDB
  38
  39    If you can control when and how system BDB is upgraded, this option
  40    saves space, removes the need to rebuild RPM in case of security etc
  41    updates to BDB and also makes build rpm itself much faster. On the other
  42    hand, major BDB upgrades can be disruptive, especially if
  43    the on-disk format changes somehow.
  44
  45    To use this method, simply pass in --with-external-db to ./configure
  46    script. If the system BDB is installed outside compiler + linker default
  47    paths, you can use CPPFLAGS and LDFLAGS to tell configure where to look,
  48    for example:
  49
  50    $ ./configure --with-external-db CPPFLAGS=-I/usr/include/db45
  51
  52 Minimal instructions for building BDB are
  53     cd build_unix
  54     ../dist/configure --with-posixmutexes
  55     make
  56     make install
  57
  58 If you want to use the alternative SQLite backend for RPM database instead
  59 of the default Berkeley DB, it can be enabled with --enable-sqlite3 option
  60 to configure. Note that the SQLite backend is not as tested as BDB.
  61 SQLite >= 3.x is required and is available from
  62     http://www.sqlite.org/
  63
  64 For embedded Lua scripting support (recommended and enabled by default),
  65 you'll need Lua >= 5.1 library + development environment installed.
  66 Note that only the library is needed at runtime, RPM never calls external
  67 Lua interpreter for anything. Lua is available from
  68     http://www.lua.org
  69
  70 If SELinux support is desired, it can be enabled with --with-selinux option
  71 to configure and libselinux development environment installed. SELinux
  72 is available from
  73     http://www.nsa.gov/selinux/
  74
  75 It may be desired to install bzip2 and gzip so that RPM can use these
  76 formats.  Gzip, is necessary to build packages that contain compressed
  77 tar balls, these are quite common on the Internet.
  78 These are availible from
  79     http://www.gzip.org
  80     http://www.bzip.org
  81
  82 If you want to build the Python bindings to RPM library, it can be enabled
  83 with --enable-python option to configure. You'll need to have Python (>= 2.3)
  84 runtime and C API development environment installed, this is available from
  85     http://www.python.org/
  86
  87 For best results you should compile with GCC and GNU Make.  Users have
  88 reported difficulty with other build tools (any patches to lift these
  89 dependencies are welcome). Both GCC and GNU Make available from
  90     http://www.gnu.org/
  91
  92 If National Language Support (NLS) is desired you will need gnu
  93 gettext (currently this is required to build rpm but we hope to
  94 lift this requirement soon), available from
  95     http://www.gnu.org/
  96
  97 If you are going to hack the sources (or compile from source repository)
  98 you will need most of the GNU development tools including:
  99 autoconf, automake, gettext, libtool, makeinfo, perl, GNU m4, GNU tar
 100 available from
 101     http://www.gnu.org/
 102
 103 If you want to build RPM API documentation, use --enable-apidocs configure
 104 option. Doxygen is needed for this, it's available at
 105     http://www.stack.nl/~dimitri/doxygen/
 106
 107 If you plan on using cryptographic signatures you will need a version
 108 of GPG, available from
 109     http://www.gnupg.org/
 110
 111 To compile RPM:
 112 --------------
 113
 114 RPM uses a small shell script to run: libtool, autoconf,
 115 automake. This step should not be necessary if you are running a
 116 released version of rpm, however if you have gotten the rpm sources
 117 directly from the source code repository, you need to generate
 118 intermediate files by running the autogen.sh script.
 119
 120 The autogen.sh script checks that the required tools are installed.
 121 The autogen.sh script also runs configure for you and passes the command line
 122 arguments to configure.  To run it without configure type:
 123
 124     ./autogen.sh --noconfigure
 125
 126 If your libraries are not in a standard place you will need to change
 127 configures environment.  These options can be passed directly to
 128 configure or to autogen.sh which will pass them through to configure.
 129
 130 Here is an example:
 131     LIBS='-L/opt/libz/ -L/opt/BerkeleyDB/lib/' \
 132     CPPFLAGS='-I/opt/libz/ -I/opt/BerkeleyDB/include' \
 133     ./configure
 134
 135 If you have build tools stored in non standard places you should check
 136 the resulting Makefile to be sure that the tools you wish to use have
 137 been correctly identified.  The configure script will modify your path
 138 before looking for the build tools and it may find versions of these
 139 tools that you do not want.  It uses the following search path
 140
 141     MYPATH="/bin:/usr/bin:/usr/local/bin:$PATH:/opt/gnu/bin"
 142
 143 now build the system with:
 144
 145     make
 146
 147 and then install with:
 148
 149     make install
 150
 151 If you wish to make a tarfile of the binaries so that you may easily
 152 install on machines with OS package managers other then rpm (ed note:
 153 what about putting gzip and bzip2 in the tar, modifying the
 154 /etc/rpmrc?):
 155
 156     make tar
 157
 158 when installing. If you do install from a tarball, you will need to do
 159 something like
 160
 161     mkdir /var/lib/rpm
 162     rpm --initdb
 163
 164 to initialize your rpm database.
 165
 166 Finally, if you wish to prepare an rpm source tar ball, you should do
 167
 168     make dist
 169
 170 To package RPM:
 171 --------------
 172
 173 After RPM has been installed you can run rpm to build an rpm package.
 174 Edit the rpm.spec file to mirror any special steps you needed to
 175 follow to make rpm compile and change the specfile to match your
 176 taste.  You will need to put the rpm source tar file into the
 177 SOURCES directory and we suggest putting the specfile in the
 178 SPECS directory, then run rpmbuild -ba rpm.spec.  You will end up
 179 with two rpms which can be found in RPMS and SRPMS.
 180
 181 If you are going to install rpm on machines with OS package managers
 182 other then rpm, you may choose to install the base rpm package via a
 183 cpio instead of a tar file.  Instead of running "make tar" during the
 184 build process, as discribed above, use the base rpm packages to create
 185 a cpio.  After the rpms have been created run rpm2cpio on the base rpm
 186 package, this will give you a cpio package which can then use to
 187 install rpm on a new system.
 188
 189     rpm2cpio rpm-4.0-1.solaris2.6-sparc.rpm > rpm-4.0-1.solaris2.6-sparc.cpio
 190
 191
 192 Non Linux Configuration Issues:
 193 ------------------------------
 194
 195
 196 OS dependencies:
 197 ----------------
 198
 199 Under RPM based Linux distributions all libraries (in fact all files
 200 distributed with the OS) are under RPM control and this section is not
 201 an issue.
 202
 203 RPM will need to be informed of all the dependencies which were
 204 satisfied before RPM was installed.  Typically this only refers to
 205 libraries that are installed by the OS, but may include other
 206 libraries and packages which are availible at the time RPM is
 207 installed and will not under RPM control.  Another common example of
 208 libraries which may need dependency provisions are precompiled
 209 libraries which are installed by the OS package manager during system
 210 build time.  The list of dependencies you will wish to load into RPM
 211 will depend on exactly how you bootstrap RPM onto your system and what
 212 parts of the sytem you put into packages as well as on the specific OS
 213 you are using.
 214
 215 The script vpkg-provides.sh can be used to generate a package which
 216 will satisfy the dependencies on your system.  To run it you will need
 217 to create a specfile header for this empty package and run the progam
 218 with:
 219
 220     --spec_header '/path/to/os-base-header.spec
 221
 222 and if you wish to ensure that some directories are not traversed you
 223 can use the option:
 224
 225     --ignore_dirs 'egrep|pattern|of|paths|to|ignore
 226
 227 By default the generated rpm will include a %verifyscript to verify
 228 checksum of all files traversed has not changed.  This additional
 229 check can be surpressed with:
 230
 231     --no_verify
 232
 233 The result of running the script will be a specfile which will create
 234 a package continging all the dependencies found on the system.  There
 235 will be one provides line for each depednecy. The package will contain
 236 none of the actual OS library files as it is assumed they are already
 237 on your system and managed by other means.  Here is a example
 238 (truncated) of the provides lines used by one user of Digital Unix. (I
 239 have put several provides on the same line for brevity)
 240
 241 provides: /bin/sh /usr/bin/ksh /usr/bin/csh
 242 provides: libc.so.osf.1 libm.so.osf.1 libcurses.so.xpg4 libdb.so.osf.1
 243 provides: libX11.so libXaw.so.6.0 libXext.so libXm.so.motif1.2 libXmu.so
 244 provides: libdnet_stub.so.osf.1 libsecurity.so.osf.1 libpthread.so.osf.1
 245 provides: libexc.so.osf.1 libmach.so.osf.1 libdps.so libdpstk.so
 246
 247
 248 The script vpkg-provides2.sh is underdevelopment as a more advanced
 249 version of vpkg-provides.sh which is aware of many different unix
 250 vendor packaging schemes.  It will create one "dependency package" for
 251 each unix package your OS vendor installed.
 252
 253
 254 rpmfilename:
 255 -----------
 256
 257 If you plan on packaging for more then one OS you may want to edit
 258 /etc/macros or /usr/lib/rpm/macros and change the line which has
 259 rpmfilename to something which include both the %{_target_os} and
 260 %{_target_cpu}.  This will cause the name of the generated rpm files
 261 to the operating system name as well as the architecture which the rpm
 262 runs under.  The line to change looks like:
 263
 264 %_rpmfilename           %%{ARCH}/%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm
 265
 266 you may wish to include both the %{_target_os} and %{_target_cpu} in
 267 the final base name, so that it's easier to distinguish between what
 268 package is appropriate for a particular arch-os-version combo.  We
 269 suggest:
 270
 271 %_rpmfilename           %%{_target_platform/%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{_target_platform}.rpm
 272
 273 There is no %{_target_os_version} tag, so if you need to also
 274 distinguish between RPMs for certain versions of the OS, you can
 275 hard-code the version in the rpmrc on the build machine, so that .rpm
 276 files are generated with the version as part of the filename.
 277
 278 For example when one user builds RPMs for Digital Unix 4.0b and 4.0d,
 279 optimization is important and he will build one set of RPMs for the
 280 EV4 processor and another set for the EV56 processor.  He specifies
 281 both the OS version (if it's important, as it is for a few packages)
 282 and the processor version by default by setting a special rpmfilename:
 283 on the particular build machine.
 284
 285 The "rpmfilename: "tag on one machine (Digital Unix 4.0d, EV56 PWS 433)
 286 looks like:
 287
 288 rpmfilename: %{_target_os}/4.0d/%{_target_cpu}/%{name}-%{version}-%{release}.%{_target_os}-%{_target_cpu}ev56.rpm
 289
 290 For package `foo-1.1', at build time that would translate into:
 291
 292     osf1/4.0d/alpha/foo-1.1-1.osf1-alphaev56.rpm
 293
 294 The hyphen between the %{_target_cpu} and ev56 is left out for compatibility
 295 with GNU Config.guess and because `alphaev56' looks more "normal" to
 296 people with an alpha than alpha-ev56 for someone on an Intel Pentium
 297 Pro would want `i586pro' over `i586-pro', but it does make parsing
 298 this filename by other programs a bit more difficult.
 299
 300
 301 GPG/PGP/PGP5
 302 ------------
 303
 304 To use the signing features of rpm, you will need to configure certain
 305 rpm macros in ~/.rpmmacros:
 306
 307         %_signature     gpg
 308         %_gpg_name      <GPG UID>
 309         %_gpg_path      %(echo $HOME)/.gnupg
 310