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     ftp://ftp.freesoftware.com/pub/infozip/zlib/
   7
   8 The Berkeley db1 and db3 libraries. These are available from
   9     http://www.sleepycat.com.
  10
  11 Minimal instructions for building db3 are (see a Red Hat dbN package
  12 spac file for more conmplete details)
  13     cd build_unix
  14     ../dist/configure --enable-compat185
  15     make
  16     make install
  17
  18 It may be desired to install bzip2 and gzip so that RPM can use these
  19 formats.  Gzip, is necessary to build packages that contain compressed
  20 tar balls, these are quite common on the Internet.
  21 These are availible from
  22     http://www.digistar.com/bzip2/index.html
  23     http://sources.redhat.com/bzip2/
  24
  25 For best results you should compile with GCC and GNU Make.  Users have
  26 reported difficulty with other build tools (any patches to lift these
  27 dependencies are welcome). Both GCC and GNU Make available from
  28     http://www.gnu.org/
  29
  30 If National Language Support (NLS) is desired you will need gnu
  31 gettext (currently this is required to build rpm but we hope to
  32 lift this requirement soon), available from
  33     http://www.gnu.org/
  34
  35 If you are going to hack the sources (or compile from anonymous cvs
  36 retrevial) you will need most of the GNU development tools including:
  37 autoconf, automake, gettext, libtool, makeinfo, perl, GNU m4, GNU tar
  38 available from
  39     http://www.gnu.org/
  40
  41 If you plan on using cryptographic signatures you will need a version
  42 of GPG.
  43
  44 Since Red Hat 6.1 uses gnupg for signing packages, previous releases were
  45 signed with pgp-2.6.3. Pgp5 can be used instead of pgp-2.6.3 signatures iff
  46 RSA signature's are used.
  47
  48 These can be downloaded (for US citizens) from:
  49     http://web.mit.edu/network/pgp.html
  50     http://www.gnu.org/
  51     http://www.pgpi.com/
  52
  53 Note: rpm-4.0 on Red Hat 7.0 is currently using
  54     zlib-1.1.3
  55     db1-1.85
  56     db3-3.1.14
  57     bzip2-1.0.1
  58     gnupg-1.0.2
  59 You may use the tarballs within those packagese, and examine the patches and
  60 spec files for details about how to build the libraries needed by rpm.
  61
  62
  63 To compile RPM:
  64 --------------
  65
  66 RPM uses a small shell script to run: libtool, autoconf,
  67 automake. This step should not be necessary if you are running a
  68 released version of rpm, however if you have gotten the rpm sources
  69 using anonymous CVS or via anonymous FTP, you should probably regenerate
  70 intermediate files by re-running the autogen.sh script.
  71
  72 The autogen.sh script checks that the required tools are installed.
  73 While other versions of the tools may be used, the script checks for
  74 the same version of the tools that was used at the time the tarball
  75 was produced. Edit the top of the script to change version numbers if you wish.
  76
  77 The autogen.sh script also runs configure for you and passes the command line
  78 arguments to configure.  To run it without configure type:
  79
  80     ./autogen.sh --noconfigure
  81
  82 If your libraries are not in a standard place you will need to change
  83 configures environment.  These options can be passed directly to
  84 configure or to autogen.sh which will pass them through to configure.
  85
  86 Here is an example:
  87     LIBS='-L/opt/libz/ -L/opt/BerkeleyDB/lib/' \
  88     CPPFLAGS='-I/opt/libz/ -I/opt/BerkeleyDB/include' \
  89     ./configure
  90
  91 If you have build tools stored in non standard places you should check
  92 the resulting Makefile to be sure that the tools you wish to use have
  93 been correctly identified.  The configure script will modify your path
  94 before looking for the build tools and it may find versions of these
  95 tools that you do not want.  It uses the following search path
  96
  97     MYPATH="/bin:/usr/bin:/usr/local/bin:$PATH:/opt/gnu/bin"
  98
  99 now build the system with:
 100
 101     make
 102
 103 and then install with:
 104
 105     make install
 106
 107 If you wish to make a tarfile of the binaries so that you may easily
 108 install on machines with OS package managers other then rpm (ed note:
 109 what about putting gzip and bzip2 in the tar, modifying the
 110 /etc/rpmrc?):
 111
 112     make tar
 113
 114 when installing. If you do install from a tarball, you will need to do
 115 something like
 116
 117     mkdir /var/lib/rpm
 118     rpm --initdb
 119
 120 to initialize your rpm database.
 121
 122 Finally, if you wish to prepare an rpm source tar ball, you should do
 123
 124     make dist
 125
 126 To package RPM:
 127 --------------
 128
 129 After RPM has been installed you can run rpm to build an rpm package.
 130 Edit the rpm.spec file to mirror any special steps you needed to
 131 follow to make rpm compile and change the specfile to match your
 132 taste.  You will need to put the rpm source tar file into the
 133 redhat/SOURCES directory and we suggest putting the specfile in the
 134 redhat/SPECS directory, then run rpmbuild -ba rpm.spec.  You will end up
 135 with two rpms which can be found in redhat/RPMS and redhat/SRPMS.
 136
 137 If you are going to install rpm on machines with OS package managers
 138 other then rpm, you may choose to install the base rpm package via a
 139 cpio instead of a tar file.  Instead of running "make tar" during the
 140 build process, as discribed above, use the base rpm packages to create
 141 a cpio.  After the rpms have been created run rpm2cpio on the base rpm
 142 package, this will give you a cpio package which can then use to
 143 install rpm on a new system.
 144
 145     rpm2cpio rpm-4.0-1.solaris2.6-sparc.rpm > rpm-4.0-1.solaris2.6-sparc.cpio
 146
 147
 148 Non Linux Configuration Issues:
 149 ------------------------------
 150
 151
 152 OS dependencies:
 153 ----------------
 154
 155 Under Red Hat Linux all libraries (in fact all files distributed with
 156 the OS) are under RPM control and this section is not 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.
 261
 262 Here's what I use for gpg:
 263
 264     /etc/rpm/macros for per-system (or ~/.rpmmacros for per-user) configuration
 265         %_signature     gpg
 266         %_gpg_name      Jeff Johnson (ARS N3NPQ) <jbj@redhat.com>
 267         %_gpg_path      /home/devel/jbj/.gnupg
 268
 269 Here's what I use for pgp2.6:
 270
 271     /etc/rpm/macros for per-system (or ~/.rpmmacros for per-user) configuration
 272         %_signature     pgp
 273         %_pgpbin        /usr/bin/pgp
 274         %_pgp_name      Jeff Johnson <jbj@redhat.com>
 275         %_pgp_path      /home/jbj/.pgp
 276
 277 In order to use pgp5, you will need to change:
 278
 279         %_signature     pgp5
 280         %_pgpbin        /path/to/pgp5/binary
 281         %_pgp_path      /path/to/pgp5/keyring
 282
 283 (Note: Only one of pgp and pgp5 may be used because of name conflicts.)
 284
 285 You may also need Red Hat GPG/PGP public keys. These can be found in the
 286 rpm source tarball, in /usr/doc/rpm*, or form http://www.redhat.com. In
 287 order to verify a package signed by Red Hat you will need to import these
 288 keys onto you key ring. See the GPG/PGP documentation for how to do this.