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