summaryrefslogtreecommitdiff
path: root/INSTALL
diff options
context:
space:
mode:
authorjbj <devnull@localhost>1999-03-14 00:34:52 +0000
committerjbj <devnull@localhost>1999-03-14 00:34:52 +0000
commit776dc9c2581c54e7ebb9980ca01401956e4f81b0 (patch)
tree408fb8b53e2caaa9331bc41a87c1e0611e33d653 /INSTALL
parentd32ae3ef069894e08929261d911ad300b9767a3a (diff)
downloadlibrpm-tizen-776dc9c2581c54e7ebb9980ca01401956e4f81b0.tar.gz
librpm-tizen-776dc9c2581c54e7ebb9980ca01401956e4f81b0.tar.bz2
librpm-tizen-776dc9c2581c54e7ebb9980ca01401956e4f81b0.zip
change support@redhat.com to rpm-list@redhat.com.
CVS patchset: 2891 CVS date: 1999/03/14 00:34:52
Diffstat (limited to 'INSTALL')
-rw-r--r--INSTALL162
1 files changed, 162 insertions, 0 deletions
diff --git a/INSTALL b/INSTALL
new file mode 100644
index 000000000..6a705172b
--- /dev/null
+++ b/INSTALL
@@ -0,0 +1,162 @@
+
+
+To build RPM you will need several other packages:
+--------------------------------------------------
+
+
+The zlib library for compression support available from
+ http://www.cdrom.com/pub/infozip/zlib/
+
+The berkeley db library db.1.85, or db.2* (currently the latest is
+db-2.6.4) with compatibility mode for db.1.85 defined. The developers
+of RPM did not upgrade RPM to use the current version of libdb because
+they are uncomfortable with changes in the softwares license. Now db2
+has a special exception license within glibc-2.1 so whatever license
+discomfort there is/was is quickly becoming moot. The remaining issue
+is that the db_185 compatibility does not work in glibc-2.1. This is
+available from
+ http://www.sleepycat.com/download.html.
+
+The instructions for building db-2.6.4:
+
+ cd build_unix
+ ../dist/configure --enable-compat185
+ make
+ make install
+
+
+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.digistar.com/bzip2/index.html
+ http://www.gnu.org/
+
+If National Language Support (NLS) is desired
+you will need gnu gettext available from
+ http://www.gnu.org/
+
+If you need support of RPM 1.x databases, which are in an old RPM
+format. You will need the GNU db library gdbm to build the rpmconvert
+binary. This is availible from :
+ http://www.gnu.org/
+
+For best results you should compile with GCC and GNU Make. Users have
+reported difficulty with other build tools. available from
+ http://www.gnu.org/
+
+
+To compile RPM:
+--------------
+
+If your libraries are in a standard place you will need to change
+the configure environment.
+
+Here is an example:
+ LIBS='-L/opt/libz/ -L/opt/BerkeleyDB/lib/' \
+ CPPFLAGS='-I/opt/libz/ -I/opt/BerkeleyDB/include' \
+ ./configure
+
+now build the system with:
+
+ make
+
+if you wish to make a tarfile of the binaries so that you may easily
+install on other machines (ed note: what about putting gzip and bzip2
+in the tar, modifying the /etc/rpmrc?):
+
+ make tar
+
+when installing do not forget to init the database (rpm --initdb)
+
+
+
+Non Linux Configuration Issues:
+------------------------------
+
+
+OS dependencies:
+----------------
+
+Under Red Hat Linux 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.
+
+You should satisfy dependencies for all shells and interpreters. A
+reasonable list of OS installed shells can be generated with:
+
+ cat /etc/shells
+
+You should satisfy dependencies for all system libraries. For each of
+the system library directories you should run
+
+ echo * | find-provides.sh
+
+(On Linux a list of system library directories can be found in
+/etc/ld.so.conf, other OS require an experienced system administrator
+to know where the libraries are.)
+
+
+You may add as many "provides: " lines as you like to /etc/rpmrc/ but
+they can not be continued. Each line is limited to 8K bytes. Here is
+a example (truncated) of the provides lines used by one user of
+Digital Unix.
+
+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
+
+
+
+rpmfilename:
+-----------
+
+If you plan on packaging for more then one OS you may want to edit
+/etc/rpmrc and change the line which has rpmfilename to something
+which include both the %{OS} and %{ARCH}. 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 %{OS} and %{ARCH} 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: %{ARCH}/%{NAME}-%{VERSION}-%{RELEASE}.%{OS}-%{ARCH}.rpm
+
+There is no %{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: %{OS}/4.0d/%{ARCH}/%{NAME}-%{VERSION}-%{RELEASE}.%{OS}-%{ARCH}-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
+
+