rpm/INSTALL

To build RPM you will need several other packages:
--------------------------------------------------

The popt library for option parsing, must be version 1.13 or later.
It is available from
    http://ftp.rpm.org/popt/

The zlib library for compression support. You might also need/want
the unzip executable for java jar dependency analysis. All available from
    http://www.gzip.org/zlib/

The libmagic (aka file) library for file type detection (used by rpmbuild). 
The source for the file utility + library is available from
    ftp://ftp.astron.com/pub/file/

You will need a cryptographic library to support digests and signatures.
This library may be libgcrypt or OpenSSL, and can be specified with the
--with-crypto=[libgcrypt|openssl] argument to configure.
libgcrypt is the default.

libgcrypt library is available from https://www.gnupg.org/software/libgcrypt/

If using the OpenSSL library for encryption, it must be version 1.0.2 or
later. Note: when compiling against OpenSSL, there is a possible license
incompatibility. For more details on this, see
https://people.gnome.org/~markmc/openssl-and-the-gpl.html
Some Linux distributions have different legal interpretations of this
possible incompatibility. It is recommended to consult with a lawyer before
building RPM against OpenSSL.
Fedora: https://fedoraproject.org/wiki/Licensing:FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F
Debian: https://lists.debian.org/debian-legal/2002/10/msg00113.html

The OpenSSL crypto library is available from https://www.openssl.org/

The Berkeley DB >= 4.3.x (4.5.x or newer recommended) is required for the
deprecated "bdb" database backend. BDB can be downloaded from
http://www.oracle.com/technology/software/products/berkeley-db/index.html

RPM supports two different ways to include it, both methods have their 
distinct advantages and disadvantages:

1) Building and using an internal copy of BDB
   
   This is the "safe" way: upgrades to system BDB can not affect your
   rpmdb integrity and you have full control over how BDB is configured. 
   On the other hand, any updates (security or bugfix) to BDB will require 
   rebuilding RPM. 

   To use this method, download a recent version of BDB from the URL above,
   expand the tarball into rpm source directory root and create "db" symlink
   to it, eg:
   $ wget http://download.oracle.com/berkeley-db/db-4.5.20.tar.gz
   $ tar xzf db-4.5.20.tar.gz
   $ ln -s db-4.5.20 db
   $ ./configure [other options...]

2) Linking to external (system) BDB

   If you can control when and how system BDB is upgraded, this option
   saves space, removes the need to rebuild RPM in case of security etc
   updates to BDB and also makes build rpm itself much faster. On the other
   hand, major BDB upgrades can be disruptive, especially if
   the on-disk format changes somehow. 

   This method is the default if no "db" link exists in the top directory.
   If the system BDB is installed outside compiler + linker default
   paths, you can use CPPFLAGS and LDFLAGS to tell configure where to look,
   for example:

   $ ./configure CPPFLAGS=-I/usr/include/db45

Minimal instructions for building BDB are 
    cd build_unix 
    ../dist/configure --with-posixmutexes
    make
    make install

For embedded Lua scripting support (recommended and enabled by default),
you'll need Lua >= 5.2 library + development environment installed.
Note that only the library is needed at runtime, RPM never calls external
Lua interpreter for anything. Lua is available from 
    http://www.lua.org

If SELinux support is desired, it can be enabled with --with-selinux option
to configure and libselinux development environment installed. SELinux
is available from
    http://www.nsa.gov/selinux/

It may be desired to install bzip2, gzip, and xz/lzma so that RPM can use these
formats.  Gzip is necessary to build packages that contain compressed
tar balls, these are quite common on the Internet.
These are available from
    http://www.gzip.org
    http://www.bzip.org
    http://tukaani.org/xz/

If you want to build the Python bindings to RPM library, it can be enabled
with --enable-python option to configure. You'll need to have Python >= 3.1
runtime and C API development environment installed. Python 2.7 support
is deprecated and will be removed in a future release but for now, you
can still build for it by passing the Python 2 interpreter name as PYTHON
on the configure line, eg
    ./configure PYTHON=python2
Python is available from:
    http://www.python.org/

To enable POSIX.1e draft 15 file capabilities support, configure with
--with-cap. You'll also need recent libcap, available from:
    http://ftp.kernel.org/pub/linux/libs/security/linux-privs/libcap2/

To enable POSIX 1003.1e draft 17 ACL verification support, configure with
--with-acl. You'll also need the ACL library, available from:
    ftp://oss.sgi.com/projects/xfs/cmd_tars/

For best results you should compile with GCC and GNU Make.  Users have
reported difficulty with other build tools (any patches to lift these
dependencies are welcome). Both GCC and GNU Make available from 
    http://www.gnu.org/

If National Language Support (NLS) is desired you will need gnu
gettext (currently this is required to build rpm but we hope to 
lift this requirement soon), available from 
    http://www.gnu.org/

If you are going to hack the sources (or compile from source repository)
you will need most of the GNU development tools including:
autoconf, automake, gettext, libtool, makeinfo, perl, GNU m4, GNU tar
available from 
    http://www.gnu.org/

If you plan on using cryptographic signatures you will need a version
of GPG, available from
    http://www.gnupg.org/

To compile RPM:
--------------

RPM uses a small shell script to run: libtool, autoconf,
automake. This step should not be necessary if you are running a
released version of rpm, however if you have gotten the rpm sources
directly from the source code repository, you need to generate
intermediate files by running the autogen.sh script.

The autogen.sh script checks that the required tools are installed.
The autogen.sh script also runs configure for you and passes the command line
arguments to configure.  To run it without configure type:

    ./autogen.sh --noconfigure

If your libraries are not in a standard place you will need to change
configures environment.  These options can be passed directly to
configure or to autogen.sh which will pass them through to configure.

Here is an example:
    LIBS='-L/opt/libz/ -L/opt/BerkeleyDB/lib/' \
    CPPFLAGS='-I/opt/libz/ -I/opt/BerkeleyDB/include' \
    ./configure

If you have build tools stored in non standard places you should check
the resulting Makefile to be sure that the tools you wish to use have
been correctly identified.  The configure script will modify your path
before looking for the build tools and it may find versions of these
tools that you do not want.  It uses the following search path

    MYPATH="/bin:/usr/bin:/usr/local/bin:$PATH:/opt/gnu/bin"

now build the system with:

    make

and then install with:

    make install

Rpm comes with an automated self-test suite. The test-suite relies heavily
on fakechroot (https://github.com/dex4er/fakechroot/) and cannot be executed
without it. Provided that fakechroot was found during configure,
it can be executed after a successful build with:

    make check

Finally, if you wish to prepare an rpm source tar ball, you should do

    make dist

To package RPM:
--------------

After RPM has been installed you can run rpm to build an rpm package.
Edit the rpm.spec file to mirror any special steps you needed to
follow to make rpm compile and change the specfile to match your
taste.  You will need to put the rpm source tar file into the
SOURCES directory and we suggest putting the specfile in the
SPECS directory, then run rpmbuild -ba rpm.spec.  You will end up
with two rpms which can be found in RPMS and SRPMS.

If you are going to install rpm on machines with OS package managers
other then rpm, you may choose to install the base rpm package via a
cpio instead of a tar file.  Instead of running "make tar" during the
build process, as described above, use the base rpm packages to create
a cpio.  After the rpms have been created run rpm2cpio on the base rpm
package, this will give you a cpio package which can then use to
install rpm on a new system.

    rpm2cpio rpm-4.0-1.solaris2.6-sparc.rpm > rpm-4.0-1.solaris2.6-sparc.cpio


Non Linux Configuration Issues:
------------------------------


OS dependencies:
----------------

Under RPM based Linux distributions all libraries (in fact all files 
distributed with the OS) are under RPM control and this section is not 
an issue.

RPM will need to be informed of all the dependencies which were
satisfied before RPM was installed.  Typically this only refers to
libraries that are installed by the OS, but may include other
libraries and packages which are available at the time RPM is
installed and will not under RPM control.  Another common example of
libraries which may need dependency provisions are precompiled
libraries which are installed by the OS package manager during system
build time.  The list of dependencies you will wish to load into RPM
will depend on exactly how you bootstrap RPM onto your system and what
parts of the system you put into packages as well as on the specific OS
you are using.

The script vpkg-provides.sh can be used to generate a package which
will satisfy the dependencies on your system.  To run it you will need
to create a specfile header for this empty package and run the progam
with:

    --spec_header '/path/to/os-base-header.spec

and if you wish to ensure that some directories are not traversed you
can use the option: 

    --ignore_dirs 'grep-E|pattern|of|paths|to|ignore

By default the generated rpm will include a %verifyscript to verify
checksum of all files traversed has not changed.  This additional
check can be suppressed with:

    --no_verify

The result of running the script will be a specfile which will create
a package continging all the dependencies found on the system.  There
will be one provides line for each depednecy. The package will contain
none of the actual OS library files as it is assumed they are already
on your system and managed by other means.  Here is a example
(truncated) of the provides lines used by one user of Digital Unix. (I
have put several provides on the same line for brevity)

provides: /bin/sh /usr/bin/ksh /usr/bin/csh 
provides: libc.so.osf.1 libm.so.osf.1 libcurses.so.xpg4 libdb.so.osf.1
provides: libX11.so libXaw.so.6.0 libXext.so libXm.so.motif1.2 libXmu.so
provides: libdnet_stub.so.osf.1 libsecurity.so.osf.1 libpthread.so.osf.1
provides: libexc.so.osf.1 libmach.so.osf.1 libdps.so libdpstk.so 


The script vpkg-provides2.sh is underdevelopment as a more advanced
version of vpkg-provides.sh which is aware of many different unix
vendor packaging schemes.  It will create one "dependency package" for
each unix package your OS vendor installed.


rpmfilename:
-----------

If you plan on packaging for more then one OS you may want to edit
/etc/macros or /usr/lib/rpm/macros and change the line which has
rpmfilename to something which include both the %{_target_os} and
%{_target_cpu}.  This will cause the name of the generated rpm files
to the operating system name as well as the architecture which the rpm
runs under.  The line to change looks like:

%_rpmfilename           %%{ARCH}/%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm

you may wish to include both the %{_target_os} and %{_target_cpu} in
the final base name, so that it's easier to distinguish between what
package is appropriate for a particular arch-os-version combo.  We
suggest:

%_rpmfilename           %%{_target_platform/%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{_target_platform}.rpm

There is no %{_target_os_version} tag, so if you need to also
distinguish between RPMs for certain versions of the OS, you can
hard-code the version in the rpmrc on the build machine, so that .rpm
files are generated with the version as part of the filename.

For example when one user builds RPMs for Digital Unix 4.0b and 4.0d,
optimization is important and he will build one set of RPMs for the
EV4 processor and another set for the EV56 processor.  He specifies
both the OS version (if it's important, as it is for a few packages)
and the processor version by default by setting a special rpmfilename:
on the particular build machine.

The "rpmfilename: "tag on one machine (Digital Unix 4.0d, EV56 PWS 433)
looks like:

rpmfilename: %{_target_os}/4.0d/%{_target_cpu}/%{name}-%{version}-%{release}.%{_target_os}-%{_target_cpu}ev56.rpm

For package `foo-1.1', at build time that would translate into:

    osf1/4.0d/alpha/foo-1.1-1.osf1-alphaev56.rpm

The hyphen between the %{_target_cpu} and ev56 is left out for compatibility
with GNU Config.guess and because `alphaev56' looks more "normal" to
people with an alpha than alpha-ev56 for someone on an Intel Pentium
Pro would want `i586pro' over `i586-pro', but it does make parsing
this filename by other programs a bit more difficult.


GPG
---

To use the signing features of rpm, you will need to configure certain
rpm macros in ~/.rpmmacros:

	%_gpg_name      <GPG UID>
	%_gpg_path      %(echo $HOME)/.gnupg