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