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