head	2.4;
access;
symbols
	rpm-4_4_8-release:2.4.4.1
	rpm-4_4_7-release:2.4.4.1
	rpm-4_4_6-release:2.4.4.1
	rpm-4_4_5-release:2.4.4.1
	rpm-4_4_4-release:2.4.4.1
	rpm-4_4_3-release:2.4.4.1
	jbj_before_tklcpatches:2.4
	rpm-4_4_2-release:2.4
	rpm-4_4_1-release:2.4
	rpm-4_4-release:2.4
	rpm-4_4:2.4.0.4
	rpm-4_3_1-start:2.4
	rpm-4_3:2.4.0.2
	rpm-4_2_1-release:2.3
	rpm-4_1_1-release:2.3
	rpm-4_2-release:2.3
	rpm-4_2:2.3.0.4
	rpm-4_1-release:2.3
	rpm-4_1:2.3.0.2
	rpm-4_0_4-release:2.2.8.1
	jbj-before-beecrypt:2.2.8.1
	rpm-4_0_3-release:2.2.8.1
	jbj_b4_rollback:2.2.8.1
	rpm-4_0_2-release:2.2.8.1
	rpm-4_0_1-release:2.2.8.1
	rpm-3_0_6-release:2.2
	rpm-4_0-release:2.2.8.1
	rpm-3_0_6:2.2
	rpm-4_0:2.2.0.8
	rpm-3_0_5:2.2.0.6
	jbj_sparc64:2.2.0.4
	rpm-3_0_4:2.2.0.2
	rpm-3_0_3:2.1.0.4
	rpm-3_0_2:2.1
	rpm-3_0:2.1.0.2
	r2-94:2.1
	r2-93:2.1
	r2-92:2.1;
locks; strict;
comment	@# @;


2.4
date	2003.04.17.14.47.19;	author jbj;	state Exp;
branches
	2.4.4.1;
next	2.3;

2.3
date	2000.08.27.19.43.51;	author jbj;	state Exp;
branches
	2.3.4.1;
next	2.2;

2.2
date	99.11.19.19.47.43;	author jbj;	state Exp;
branches
	2.2.8.1;
next	2.1;

2.1
date	99.03.14.00.34.54;	author jbj;	state Exp;
branches;
next	;

2.2.8.1
date	2000.08.24.20.26.27;	author jbj;	state Exp;
branches;
next	;

2.3.4.1
date	2003.12.01.21.58.09;	author jbj;	state Exp;
branches;
next	;

2.4.4.1
date	2005.10.25.21.25.08;	author jbj;	state Exp;
branches;
next	;


desc
@@


2.4
log
@rpmbuiod, not rpm, -ba.
@
text
@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
    ftp://ftp.freesoftware.com/pub/infozip/zlib/

The Berkeley db1 and db3 libraries. These are available from
    http://www.sleepycat.com.

Minimal instructions for building db3 are (see a Red Hat dbN package
spac file for more conmplete details)
    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://sources.redhat.com/bzip2/

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 anonymous cvs
retrevial) 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.

Since Red Hat 6.1 uses gnupg for signing packages, previous releases were
signed with pgp-2.6.3. Pgp5 can be used instead of pgp-2.6.3 signatures iff
RSA signature's are used.

These can be downloaded (for US citizens) from:
    http://web.mit.edu/network/pgp.html
    http://www.gnu.org/
    http://www.pgpi.com/

Note: rpm-4.0 on Red Hat 7.0 is currently using
    zlib-1.1.3
    db1-1.85
    db3-3.1.14
    bzip2-1.0.1
    gnupg-1.0.2
You may use the tarballs within those packagese, and examine the patches and
spec files for details about how to build the libraries needed by rpm.


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
using anonymous CVS or via anonymous FTP, you should probably regenerate
intermediate files by re-running the autogen.sh script.

The autogen.sh script checks that the required tools are installed.
While other versions of the tools may be used, the script checks for
the same version of the tools that was used at the time the tarball
was produced. Edit the top of the script to change version numbers if you wish.

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
redhat/SOURCES directory and we suggest putting the specfile in the
redhat/SPECS directory, then run rpmbuild -ba rpm.spec.  You will end up
with two rpms which can be found in redhat/RPMS and redhat/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 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.

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.

Here's what I use for gpg:

    /etc/rpm/macros for per-system (or ~/.rpmmacros for per-user) configuration
	%_signature     gpg
	%_gpg_name      Jeff Johnson (ARS N3NPQ) <jbj@@redhat.com>
	%_gpg_path      /home/devel/jbj/.gnupg

Here's what I use for pgp2.6:

    /etc/rpm/macros for per-system (or ~/.rpmmacros for per-user) configuration
	%_signature	pgp
	%_pgpbin	/usr/bin/pgp
	%_pgp_name	Jeff Johnson <jbj@@redhat.com>
	%_pgp_path	/home/jbj/.pgp

In order to use pgp5, you will need to change:

	%_signature	pgp5
	%_pgpbin	/path/to/pgp5/binary
	%_pgp_path	/path/to/pgp5/keyring

(Note: Only one of pgp and pgp5 may be used because of name conflicts.)

You may also need Red Hat GPG/PGP public keys. These can be found in the
rpm source tarball, in /usr/doc/rpm*, or form http://www.redhat.com. In
order to verify a package signed by Red Hat you will need to import these
keys onto you key ring. See the GPG/PGP documentation for how to do this.
@


2.4.4.1
log
@Revector doco to wraptastic.org.
@
text
@d133 3
a135 3
rpm/SOURCES directory and we suggest putting the specfile in the
rpm/SPECS directory, then run rpmbuild -ba rpm.spec.  You will end up
with two rpms which can be found in rpm/RPMS and rpm/SRPMS.
d286 1
a286 1
rpm source tarball, in /usr/share/doc/rpm*, or from http://www.redhat.com. In
@


2.3
log
@Rip out rpmrc configuration.
@
text
@d134 1
a134 1
redhat/SPECS directory, then run rpm -ba rpm.spec.  You will end up
@


2.3.4.1
log
@- unify signal handling in librpmio, use condvar to deliver signal.
@
text
@d134 1
a134 1
redhat/SPECS directory, then run rpmbuild -ba rpm.spec.  You will end up
@


2.2
log
@Add reminder to export shell variables.
@
text
@a0 2


d4 13
a16 21

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

d22 2
a23 11
	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/
d26 35
a60 2
reported difficulty with other build tools.  available from
	http://www.gnu.org/
d66 19
a84 2
If your libraries are in a standard place you will need to change
the configure environment.
d87 11
a97 4
	LIBS='-L/opt/libz/ -L/opt/BerkeleyDB/lib/' \
	CPPFLAGS='-I/opt/libz/ -I/opt/BerkeleyDB/include' \
	export LIBS CPPFLAGS
	./configure
d101 5
a105 1
	make
d107 4
a110 3
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?):
d112 1
a112 1
	make tar
d114 2
a115 1
when installing do not forget to init the database (rpm --initdb)
d117 29
d170 25
a194 19
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.
d203 5
d213 19
a231 17
/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.
d243 1
a243 1
rpmfilename: %{OS}/4.0d/%{ARCH}/%{NAME}-%{VERSION}-%{RELEASE}.%{OS}-%{ARCH}-ev56.rpm
d247 35
a281 1
	osf1/4.0d/alpha/foo-1.1-1.osf1-alphaev56.rpm
d283 1
d285 4
@


2.2.8.1
log
@Updated.
@
text
@d1 2
d6 21
a26 13
The zlib library for compression support. You might also need/want
the zip executable for java jar dependency analysis. All available from
    ftp://ftp.freesoftware.com/pub/infozip/zlib/

The Berkeley db1 and db3 libraries. These are available from
    http://www.sleepycat.com.

Minimal instructions for building db3 are (see a Red Hat dbN package
spac file for more conmplete details)
    cd build_unix 
    ../dist/configure --enable-compat185
    make
    make install
d32 11
a42 2
    http://www.digistar.com/bzip2/index.html
    http://sources.redhat.com/bzip2/
d45 2
a46 35
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 anonymous cvs
retrevial) 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.

Since Red Hat 6.1 uses gnupg for signing packages, previous releases were
signed with pgp-2.6.3. Pgp5 can be used instead of pgp-2.6.3 signatures iff
RSA signature's are used.

These can be downloaded (for US citizens) from:
    http://web.mit.edu/network/pgp.html
    http://www.gnu.org/
    http://www.pgpi.com/

Note: rpm-4.0 on Red Hat 7.0 is currently using
    zlib-1.1.3
    db1-1.85
    db3-3.1.14
    bzip2-1.0.1
    gnupg-1.0.2
You may use the tarballs within those packagese, and examine the patches and
spec files for details about how to build the libraries needed by rpm.
d52 2
a53 19
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
using anonymous CVS or via anonymous FTP, you should probably regenerate
intermediate files by re-running the autogen.sh script.

The autogen.sh script checks that the required tools are installed.
While other versions of the tools may be used, the script checks for
the same version of the tools that was used at the time the tarball
was produced. Edit the top of the script to change version numbers if you wish.

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.
d56 4
a59 11
    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"
d63 1
a63 5
    make

and then install with:

    make install
d65 3
a67 4
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?):
d69 1
a69 1
    make tar
d71 1
a71 2
when installing. If you do install from a tarball, you will need to do
something like
a72 29
    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
redhat/SOURCES directory and we suggest putting the specfile in the
redhat/SPECS directory, then run rpm -ba rpm.spec.  You will end up
with two rpms which can be found in redhat/RPMS and redhat/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
d97 19
a115 25
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)
a123 5
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.

d129 17
a145 19
/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.
d157 1
a157 1
rpmfilename: %{_target_os}/4.0d/%{_target_cpu}/%{name}-%{version}-%{release}.%{_target_os}-%{_target_cpu}ev56.rpm
d161 1
a161 35
    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.

Here's what I use for gpg:

    /etc/rpm/macros for per-system (or ~/.rpmmacros for per-user) configuration
	%_signature     gpg
	%_gpg_name      Jeff Johnson (ARS N3NPQ) <jbj@@redhat.com>
	%_gpg_path      /home/devel/jbj/.gnupg

Here's what I use for pgp2.6:

    /etc/rpm/macros for per-system (or ~/.rpmmacros for per-user) configuration
	%_signature	pgp
	%_pgpbin	/usr/bin/pgp
	%_pgp_name	Jeff Johnson <jbj@@redhat.com>
	%_pgp_path	/home/jbj/.pgp

In order to use pgp5, you will need to change:

	%_signature	pgp5
	%_pgpbin	/path/to/pgp5/binary
	%_pgp_path	/path/to/pgp5/keyring
a162 1
(Note: Only one of pgp and pgp5 may be used because of name conflicts.)
a163 4
You may also need Red Hat GPG/PGP public keys. These can be found in the
rpm source tarball, in /usr/doc/rpm*, or form http://www.redhat.com. In
order to verify a package signed by Red Hat you will need to import these
keys onto you key ring. See the GPG/PGP documentation for how to do this.
@


2.1
log
@change support@@redhat.com to rpm-list@@redhat.com.
@
text
@d58 1
@

