269 lines
10 KiB
Plaintext
269 lines
10 KiB
Plaintext
To build RPM you will need several other packages:
|
|
--------------------------------------------------
|
|
|
|
The zlib library for compression support. You might also need/want
|
|
the zip executable for java jar dependency analysis. All available from
|
|
http://www.gzip.org/zlib/
|
|
|
|
The NSS library for encryption. This is available from
|
|
http://www.mozilla.org/projects/security/pki/nss/
|
|
|
|
The Berkeley DB >= 4.3.x (4.5.x or newer recommended). RPM includes an
|
|
internal copy which is used by default, but if you want to use an external
|
|
BDB (--with-external-db) it's available at
|
|
http://www.oracle.com/technology/software/products/berkeley-db/index.html
|
|
|
|
Minimal instructions for building BDB are
|
|
cd build_unix
|
|
../dist/configure --with-posixmutexes
|
|
make
|
|
make install
|
|
|
|
If you want to use the alternative SQLite backend for RPM database instead
|
|
of the default Berkeley DB, it can be enabled with --enable-sqlite3 option
|
|
to configure. Note that the SQLite backend is not as tested as BDB.
|
|
SQLite >= 3.x is required and is available from
|
|
http://www.sqlite.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 and gzip 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 availible from
|
|
http://www.gzip.org
|
|
http://www.bzip.org
|
|
|
|
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 (>= 2.3)
|
|
runtime and C API development environment installed, this is available from
|
|
http://www.python.org/
|
|
|
|
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 want to build RPM API documentation, use --enable-apidocs configure
|
|
option. Doxygen is needed for this, it's available at
|
|
http://www.stack.nl/~dimitri/doxygen/
|
|
|
|
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
|
|
|
|
If you wish to make a tarfile of the binaries so that you may easily
|
|
install on machines with OS package managers other then rpm (ed note:
|
|
what about putting gzip and bzip2 in the tar, modifying the
|
|
/etc/rpmrc?):
|
|
|
|
make tar
|
|
|
|
when installing. If you do install from a tarball, you will need to do
|
|
something like
|
|
|
|
mkdir /var/lib/rpm
|
|
rpm --initdb
|
|
|
|
to initialize your rpm database.
|
|
|
|
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 discribed 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 availible 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 sytem 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 'egrep|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 surpressed 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/PGP/PGP5
|
|
------------
|
|
|
|
To use the signing features of rpm, you will need to configure certain
|
|
rpm macros in ~/.rpmmacros:
|
|
|
|
%_signature gpg
|
|
%_gpg_name <GPG UID>
|
|
%_gpg_path %(echo $HOME)/.gnupg
|
|
|