Re: Having problems with rpm --rebuild

[kbk shore net (Kurt B. Kaiser)]

David Stuart <dstuartspam@rogers.com> writes:

> > rpm -vv -i NVIDIA_kernel-1.0-2960.src.rpm  to just verbosely
> > "install" the src.rpm i.e. position its files in the
> >rpm build tree.
> >
> 
> That also seems to work. Well, insofar as putting it into my ~/rpm
> directory.

You should now have the tar archives, patch files, and miscellaneous
files below .../rpm/SOURCES/ and the .spec file in .../rpm/SPECS/

OK, this is a big step in the right direction.  You "installed" the
src.rpm.  That's step 5.A. below.

Now unpack the archives into the BUILD tree and patch them (-bp).
Watch the permissions carefully :)

Configuration, compilation, and installation into a temporary location
follow under control of the .spec file.  Finally, a binary RPM is
created (-bb) by packaging up the files from the temporary install
tree.  (This step recreates the BUILD tree to make sure everything is
clean.)  The reason for -bp, -bc, and -bi is to allow the -ba procedure
to be broken into smaller steps in case of troubles like yours.

The procedures below create logs for review at each step.  If there's
a problem, post the relevant section from your log to the list if it
seems like it would be helpful in troubleshooting.  Each log should
end without an error.

I'd be very interested in any comments/improvements on the mini-HOWTO
from you and others on the list.

Regards, KBK

======================================================================
======================================================================

RPM: Building Binary Packages From Source RPMs mini-HOWTO

Kurt B. Kaiser  kbk@shore.net  
Version 0.13  24 April 2002

How to build and install RPM packages starting with a SRC RPM package instead
of a binary RPM

1. INTRODUCTION.  

   While binary RPMs provide a convenient way to upgrade software, it often
   happens that the desired version has dependencies or incompatibilities with
   the target system libraries, and the binary RPM cannot be installed without
   a massive system upgrade.  In that case, it may be better to build a binary
   RPM on the target system from a recent source RPM.

   Installing software from a source RPM has significant advantages over
   building from upstream sources using the traditional ./configure, make, make
   install approach.  First, the RPM database is maintained, allowing query,
   upgrade, and uninstall.  Second, the sources have usually been patched for
   your distribution and architecture.

   It is sometimes desirable to make small changes to the software prior to
   installation.  An example would be to add support to Ghostscript for a
   specific printer.  Also, there will be cases where the source RPM won't
   build correctly due to a typo, or a macro was used which is not recognized
   by your version of RPM.

   If changes to the source are made via the .spec file and patch files as
   suggested below, an audit trail can be established which in the revised
   source RPM.  However, the audit trail is not as rigorous as CVS, and it is
   up to the maintainer to leave a proper record of the changes made in the
   .spec file.

   The existing RPM documentation is oriented either towards simple
   installation of binary RPMs or towards constructing source RPMs from the
   original source archives.  Learning enough to reliably create binary RPMs
   from source RPMs can involve reading a large part of the rather extensive
   documentation on RPM.

   The purpose of this HOWTO is to provide a concise guide to this essentially
   straightforward procedure.

   To avoid the risks associated with building RPMs as root, this procedure
   requires root permissions only when installing the binary RPM.


2. SYSTEM CONFIGURATION.

   A. Create an .rpmmacros file to instruct rpm to build in a directory off
      your home directory. (This version of .rpmmacros could also be placed in
      /etc/skel/.bashrc)
   
        cd
        cat <<EOF > .rpmmacros
        %HOME       %{expand:%%(cd; pwd)}
        %_topdir    %{HOME}/rpm
        EOF

   B. Create the rpm directory structure in your home directory:

        mkdir rpm
        cd rpm
        mkdir BUILD RPMS SOURCES SPECS SRPMS
        cd

3. SOURCE RPM ACQUISITION.
   
   Download the .src.rpm to your home directory.  The www.rpmfind.net site will
   probably have what you need.  Be sure that the source RPM is designed for
   your system.  Don't forget that installation is done with root permissions,
   so be careful to get your source from a trustworthy location.


4. ONE STEP BUILD PROCEDURE.

   A. You can usually build the binary RPM in one step. The following command
      will "install" the sources, create a binary RPM, and clean up the rpm
      subdirectories when it's done (Note 1):

        rpm --rebuild foo-1.0.0-1.src.rpm  &> rebuild.log

      Examine rebuild.log to be sure that the build completed successfully.  

   B. Install the binary .rpm package, updating the rpm database.  The binary
      RPM you just created is located in the RPMS directory tree:

        cd ~/rpm/RPMS/i386      (for 386 architecture)
        su
        rpm -Uvh foo-1.0.0-1.i386.rpm
        exit

   That's all there is to it, in most cases!  But if the build errors out, or
   if you want to make some changes in the sources, then you need to follow the
   Detailed Build Procedure.


5. DETAILED BUILD PROCEDURE.

   A. Install the source RPM.  rpm will place the source tar archives and
      patches in ~/rpm/SOURCE.  The spec file, foo.spec, will be in located
      in ~/rpm/SPECS:

        cd 
        rpm -i foo-1.0.0-1.src.rpm

   B. Unpack the source tar archives into the BUILD tree and apply the patches
      in SOURCE to the BUILD tree, with a record of the steps taken saved in
      bp.log:
        
        cd rpm/SPECS
	rpm -bp foo.spec   &> bp.log

      (At this point see Appendix A for suggestions on how to make small
      changes to the sources prior to building the package.  However, it is
      usually not necessary to make changes to get a successful build.)

   C. Build the binary .rpm package (Note 2):

        rpm -bb --clean foo.spec  &> bb.log

      Always inspect the bb.log to assure that the build was error-free!

   D. Install the binary .rpm package, updating the rpm database:

        cd ~/rpm/RPMS/i386      (for 386 architecture)
        su
        rpm -Uvh foo-1.0.0-1.i386.rpm
        exit

   E. Clean up the rpm/ directories.  Cleaning can be done with rm commands or
      the SOURCE and SPEC directories can be cleaned out with:

        cd ~/rpm/SPEC
        rpm --rmsource foo.spec  (This switch could be added in the -bb step)
        rm foo.spec


APPENDIX A - SOURCE MODIFICATION
================================

There are times when it is necessary to make changes to the sources before
building the binary RPM.  If the changes are extensive, the best method is to
create a patch file and add it to the SOURCE directory and the .spec file. The
techniques for doing that are not difficult, but they are beyond the scope of
this HOWTO.  You will need to study the man pages for diff and patch, read the
appropriate sections from MaximumRPM, and review several .spec files if you
want learn how to do it.

The policy when building RPMs is that changes should never be made to the
original "pristine" source archives.  Instead, patch files and the .spec file
are used to modify the BUILD tree during the build process, and the .spec file
can also tailor the installation.

However, small changes can easily be made by using echo and sed commands in the
.spec file.

A1. Study the code in the BUILD tree and the ..../SPEC/foo.spec file until it
    becomes clear how the build works and what changes are necessary  :-)

A2. You can add commands to the at the beginning of the %build section of the
    .spec file to make changes to the Makefile (or any other file in the BUILD
    tree).  Use echo with >> to append lines to the end of a file, and sed to
    make simple changes in the middle of a file.  Study .spec files to see
    examples of how to do this.

A3. Add comments to the top of the %changelog script (with the date in the
    proper format) describing the changes which have been made.

A4. Change the Release tag in the .spec file: e.g. 1 to 1a.  An alpha suffix is
    recommended for changes not made by the package owner.

A5. Repeat the rpm -bp command, inspect the new BUILD tree, and iterate until
    you get the BUILD tree the way you want it.

A6. In the following step rpm will do the equivalent of a "make install", but
    in a temporary staging area (Note 3):

        rpm -bi --short-circuit foo.spec  &> bi.log

A7. If all is well, you will want to build both a binary RPM and a new source
    RPM.  The latter will contain your changes, and will be found in rpm/SRPMS.

        rpm -ba foo.spec  &> ba.log

    Always inspect the ba.log to be sure that everything completed without
    error.


NOTES 
===== 

1. The &> redirection operator is a bash shortcut.  If it doesn't work for you,
   modify the command as follows:

        rpm --rebuild foo-1.0.0-1.src.rpm  >  rebuild.log  2>&1


2. If the .src.rpm was not designed to install in a "staging area," (i.e. make
   its working install in a world-writable location like /var/tmp by setting
   the Buildroot macro in the .spec file), you will get a permissions error.
   If you can do so, fix the .src.rpm.  However, this may be a sizeable job,
   and you may decide to do -bi, -bb, -bs, and -ba as the root user :-( .
   
   Always check the bX.log to make sure rpm completed without errors!  If it is
   necessary to go root, use

        su -p   

   to preserve the environment set by .rpmmacros.  Otherwise, rpm will be
   looking in /usr/src/redhat/SOURCES for its files!  (It will also be
   necessary to do the cleanup as root.)  

   The install phase of a .src.rpm build is only used to set up the
   configuration which will be packaged in the binary .rpm, and really should
   be deleted after the .rpm is created.  It is not intended to be the system
   install, since the RPM database is not updated.  Nonetheless, sometimes this
   install is done in standard locations like /usr/bin and not properly
   removed.

   Troubleshooting hint: GNU make supports using the DESTDIR variable to
   specify a staging area, and a typical %install script command is

        make DESTDIR=$BUILD_ROOT install

   Another approach is to use the %makeinstall macro in the %install script.


3. If problems are experienced with -bi, it may be useful to do compiles with
   -bc until the bugs are worked out. The --short-circuit switch is helpful
   when building big source packages since it avoids going back to the unpack
   stage each time -bc or -bi is run.


4. For further documentation, consult the RPM-HOWTO, the RPM man page, the book
   _Maximum RPM_ by Ed Bailey, and the www.rpm.org web site.  Much of this
   documentation is rather out of date as of this writing, so also review the
   files in your /usr/lib/rpm-x.x.x and also the /usr/src/rpm/macros file.
   Searching the linux.redhat.rpm group on groups.google.com is helpful if all
   else fails.


ACKNOWLEDGEMENTS
================ 

The documentation at www.rpm.org, the participants on rpm-list@redhat.com
(Usenet linux.redhat.rpm) and particularly:

John Thompson showed the way and got me started on .src RPMs 

Ned Ulbricht clarified how to install source RPMs and build without being root

Jim Knoble provided a relocatable way of creating the .rpmmacros file

Tzafrir Cohen reviewed the draft and made many helpful suggestions.

Any errors are my responsibility and due to my lack of understanding of what
these people tried to explain to me.  Corrections and suggestions will be
appreciated.

HISTORY
=======

27 Jan 2002 - Kurt B. Kaiser - Initial release
30 Apr 2002 - Kurt B. Kaiser - Change title, update, submit for review

COPYING
=======

(C) Copyright 2002 Kurt B. Kaiser

Permission is granted to copy, distribute and/or modify this document under the
terms of the GNU Free Documentation License, Version 1.1 or any later version
published by the Free Software Foundation; there are no Invariant Sections, no
Front-Cover Texts and no Back-Cover Texts.  The contents of the
Acknowledgements, History, and Copying sections must be preserved, but may be
appended.

$Id: src_rpm_minihowto.txt,v 1.4 2002/05/01 01:22:15 kbk Exp $