RPM HOWTO: RPM at Idle build.htmlPrev multi-arch.htmlNext 7. Building It 
7.1. The Source Directory Tree 
	The first thing you need is a properly configured build tree.  This is
	configurable using the 
/etc/rpmrc file.  Most
	people will just use 
/usr/src.
      
	You may need to create the following directories to make a build
	tree:
      
	    BUILD is the directory where all building
	    occurs by RPM.  You don't have to do your test building anywhere in
	    particular, but this is where RPM will do it's building.
	  
	    SOURCES is the directory where you should
	    put your original source tar files and your patches.  This is where
	    RPM will look by default.
	  
	    SPECS is the directory where all spec files
	    should go.
	  
	    RPMS is where RPM will put all binary RPMs
	    when built.
	  
	    SRPMS is where all source RPMs will be put.
	  
7.2. Test Building 
	The first thing you'll probably want to to is get the source to build
	cleanly without using RPM.  To do this, unpack the sources, and change
	the directory name to $NAME.orig.  Then unpack the source again.
	Use this source to build from.  Go into the source directory and follow
	the instructions to build it.  If you have to edit things, you'll need a
	patch.  Once you get it to build, clean the source directory.  Make sure
	and remove any files that get made from a 
configure	script.  Then 
cd back out of the source directory to
	its parent.  Then you'll do something like:
      
diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch
      
	This will create a patch for you that you can use in your spec file.
	Note that the "linux" that you see in the patch name is just an
	identifier.  You might want to use something more descriptive like
	"config" or "bugs" to describe 
why you had to
	make a patch.  It's also a good idea to look at the patch file you are
	creating before using it to make sure no binaries were included by
	accident.
      
7.3. Generating the File List 
	Now that you have source that will build and you know how to do it,
	build it and install it.  Look at the output of the install sequence and
	build your file list from that to use in the spec file.  We usually
	build the spec file in parallel with all of these steps.  You can create
	the initial one and fill in the easy parts, and then fill in the other
	steps as you go.
      
7.4. Building the Package with RPM 
	Once you have a spec file, you are ready to try and build your
	package.  The most useful way to do it is with a command like the
	following:
      
rpm -ba foobar-1.0.spec
      
	There are other options useful with the -b switch as well:
      
	    p means just run the
	    
prep section of the specfile.
	  
	    l is a list check that does
	    some checks on 
%files.
	  
	    c do a prep and compile.  This
	    is useful when you are unsure of whether your source will build at
	    all.  It seems useless because you might want to just keep playing
	    with the source itself until it builds and then start using RPM, but
	    once you become accustomed to using RPM you will find instances when
	    you will use it.
	  
	    ido a prep, compile, and
	    install.
	  
	    b prep, compile, install, and
	    build a binary package only.
	  
	    abuild it all (both source and
	    binary packages).
	  
	There are several modifiers to the -b switch.  They are as follows:
      
	    --short-circuit will skip
	    straight to a specified stage (can only be used with c and i).
	  
	    --clean removes the build tree
	    when done.
	  
	    --keep-temps will keep all the
	    temp files and scripts that were made in /tmp.  You can actually see
	    what files were created in /tmp using the 
-v option.
	  
	    --test does not execute any
	    real stages, but does keep-temp.
	  
7.5. Testing It 
	Once you have a source and binary rpm for your package, you need to test
	it.  The easiest and best way is to use a totally different machine from
	the one you are building on to test.  After all, you've just done a lot
	of 
make install's on your own machine, so it should
	be installed fairly well.
      
	You can do an rpm -e packagename on the package to
	test, but that can be deceiving because in building the package, you did
	a 
make install.  If you left something out of your
	file list, it will not get uninstalled.  You'll then reinstall the
	binary package and your system will be complete again, but your rpm
	still isn't.  Make sure and keep in mind that just because you do a
	
rpm -ba package, most people installing your package
	will just be doing the 
rpm -i package.  Make sure you
	don't do anything in the 
build or
	
install sections that will need to be done when
	the binaries are installed by themselves.
      
7.6. What to do with your new RPMs 
	Once you've made your own RPM of something (assuming its something that
	hasn't already been RPM'ed), you can contribute your work to others
	(also assuming you RPM'ed something freely distributable).  To do so,
	you'll want to upload it to 
ftp://ftp.redhat.comftp.redhat.com .
      
7.7. What Now? 
	Please see the above sections on Testing and What to do with new RPMs.
	We want all the RPMs available we can get, and we want them to be good
	RPMs.  Please take the time to test them well, and then take the time to
	upload them for everyone's benefit.  Also, 
please	make sure you are only uploading 
freely available
	software
.  Commercial software and shareware should
	
not be uploaded unless they have a copyright
	expressly stating that this is allowed.  This includes ssh, pgp, etc.
      
build.htmlPrev index.htmlHome multi-arch.htmlNext Building RPMs  Multi-architectural RPM Building 