RPM Help

The Spec File 

Spec files are required to build a package. The spec file is a description of the software along with instructions on how to build it and a file list for all the binaries that get installed.
Sample Spec File
%define name LnxZip
%define version 0.1
%define release 1
%define prefix /usr
Summary : LnxZip a WinZip(tm) clone and RPM builder for Linux Gnome
Name: %{name}
Version: %{version}
Release: %{release}
Copyright: GPL
Group: Applications/File
Source: %{name}-%{version}-%{release}.tar.bz2
BuildRoot: /var/tmp/%{name}-buildroot
Prefix: %{prefix}
Docdir: %{prefix}/doc

%description
LnxZip  is a Gnome front-end to common archive utilities under Linux/unix. The goal is to provide the end user 
with a quality tool he/she requires to either work with compressed files or create RPM's. 

Currently zip, gzip, tar, arj, and bzip2 are supported. Functionality includes the ability to open archives, 
and to add, delete, extract, and view files.  RPM functionality includes creation of spec file, automatic 
naming convention, creation of build scripts, creation of build tree and execution of build script.

%prep
 rm -rf $RPM_BUILD_ROOT

%setup
 ./configure

%build
 make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"

%install
make prefix=$RPM_BUILD_ROOT%{prefix} install

%clean
 rm -rf $RPM_BUILD_ROOT
rm -rf $RPM_BUILD_DIR/*

%files
%defattr (-,root,root)
%doc COPYING
/usr/bin/lnxzip
/usr/share/gnome/apps/Utilities/gnome-lnxzip.desktop
/usr/share/pixmaps/gnome-lnxzip.png
/usr/share/mime-info/gnome-lnxzip.keys

%changelog

The Header

The header has some standard fields in it that you need to fill in. There are a few caveats as well. The fields must be filled in as follows:
%summary This is a one line description of the package.
%name This must be the name string from the rpm filename you plan to use. 
%version This must be the version string from the rpm filename you plan to use.
%release This is the release number for a package of the same version.
%copyright This line tells how a package is copyrighted. You should use something like GPL, BSD, MIT, public domain, distributable, or commercial. 
%group This line is used to tell high level installation programs (such as Red Hat's gnorpm or Kde Kpackage) where to place this particular program in its hierarchical structure. 
 
                
Amusements/Games
Amusements/Graphics
Applications/Archiving
Applications/Communications
Applications/Databases
Applications/Editors
Applications/Emulators
Applications/Engineering
Applications/File
Applications/Internet
Applications/Multimedia
Applications/Productivity
Applications/Publishing
Applications/System
Applications/Text
Development/Debuggers
Development/Languages
Development/Libraries
Development/System
Development/Tools
Documentation
System Environment/Base
System Environment/Daemons
System Environment/Kernel
System Environment/Libraries
System Environment/Shells
User Interface/Desktops
User Interface/X
User Interface/X Hardware Support
 
%source This line points at the HOME location of the pristine source file. It is used if you ever want to get the source again or check for newer versions. Caveat: The filename in this line MUST match the filename you have on your own system (ie. don't download the source file and change its name). You can also specify more than one source file using lines like: 
 
               
Source0: blah-0.tar.gz
Source1: blah-1.tar.gz
Source2: fooblah.tar.gz
 
Not supported at this time in LnxZip. These files would go in the SOURCES directory. 
%patch This is the place you can find the patch if you need to download it again.
Patch0: blah-0.patch
Patch1: blah-1.patch
Patch3: fooblah.patch
 
Not supported at this time in LnxZip. These files would go in the SOURCES directory.
%buildroot This line allows you to specify a directory as the "root" for building and installing the new package. You can use this to help test your package before having it installed on your machine. 
%description It's not really a header item, but should be described with the rest of the header. You need one description tag per package and/or subpackage. This is a multi-line field that should be used to give a comprehensive description of the package. 

Prep

This is the second section in the spec file. It is used to get the sources ready to build. Here you need to do anything necessary to get the sources patched and setup like they need to be setup to do a make.

 One thing to note: Each of these sections is really just a place to execute shell scripts. You could simply make an sh script and put it after the %prep tag to unpack and patch your sources. We have made macros to aid in this, however.

 The first of these macros is the %setup macro. In its simplest form (no command line options), it simply unpacks the sources and cd's into the source directory. It also takes the following options: 

-n name will set the name of the build directory to the listed name. The default is $NAME-$VERSION. Other possibilities include $NAME, ${NAME}${VERSION}, or whatever the main tar file uses. (Please note that these "$" variables are not real variables available within the spec file. They are really just used here in place of a sample name. You need to use the real name and version in your package, not a variable.) 

-c will create and cd to the named directory before doing the unta

 -b # will untar Source# before cd'ing into the directory (and this makes no sense with -c so don't do it). This is only useful with multiple source files.

 -a # will untar Source# after cd'ing into the directory.

 -T This option overrides the default action of untarring the Source and requires a -b 0 or -a 0 to get the main source file untarred. You need this when there are secondary sources. 

-D Do not delete the directory before unpacking. This is only useful where you have more than one setup macro. It should only be used in setup macros after the first one (but never in the first one). 

The next of the available macros is the %patch macro. This macro helps automate the process of applying patches to the sources. It takes several options, listed below: 

# will apply Patch# as the patch file. 

-p # specifies the number of directories to strip for the patch(1) command. 

-P The default action is to apply Patch (or Patch0). This flag inhibits the default action and will require a 0 to get the main source file untarred. This option is useful in a second (or later) %patch macro that required a different number than the first macro.

 You can also do %patch# instead of doing the real command: %patch # -P 

-b extension will save originals as filename.extension before patching.

 That should be all the macros you need. After you have those right, you can also do any other setup you need to do via sh type scripting. Anything you include up until the %build macro (discussed in the next section) is executed via sh. Look at the example above for the types of things you might want to do here. 

Build 

There aren't really any macros for this section. You should just put any commands here that you would need to use to build the software once you had untarred the source, patched it, and cd'ed into the directory. This is just another set of commands passed to sh, so any legal sh commands can go here (including comments). 

Your current working directory is reset in each of these sections to the toplevel of the source directory, so keep that in mind. You can cd into subdirectories if necessary.

 The variable RPM_OPT_FLAGS is set using values in /usr/lib/rpm/rpmrc. Look there to make sure you are using values appropriate for your system (in most cases you are). Or simply don't use this variable in your spec file. It is optional.

 

Install 

There aren't really any macros here, either. You basically just want to put whatever commands here that are necessary to install. If you have make install available to you in the package you are building, put that here. If not, you can either patch the makefile for a make install and just do a make install here, or you can hand install them here with sh commands. You can consider your current directory to be the toplevel of the source directory. 

The variable RPM_BUILD_ROOT is available to tell you the path set as the Buildroot: in the header. Using build roots are optional but are highly recommended because they keep you from cluttering your system with software that isn't in your RPM database (building an RPM doesn't touch your database...you must go install the binary RPM you just built to do that). 

Cleaning your system

It's a good idea to always make sure there is a clean build root before building a package a second time on a system. The %clean macro will help with that. Simply put the proper commands there to blow away a former build root. Anal, err, careful folks may want to test that RPM_BUILD_ROOT wasn't set to / before doing something this volatile.

 

Optional pre & post Install/Uninstall Scripts

You can put scripts in that get run before and after the installation and uninstallation of binary packages. A main reason for this is to do things like run ldconfig after installing or removing packages that contain shared libraries. The macros for each of the scripts is as follows: 

%pre is the macro to do pre-install scripts. 

%post is the macro to do post-install scripts.

 %preun is the macro to do pre-uninstall scripts. 

%postun is the macro to do post-uninstall scripts. 

The contents of these sections should just be any sh style script, though you do not need the #!/bin/sh. 

Files 

This is the section where you must list the files for the binary package. RPM has no way to know what binaries get installed as a result of make install. There is NO way to do this. Some have suggested doing a find before and after the package install. With a multiuser system, this is unacceptable as other files may be created during a package building process that have nothing to do with the package itself. 

There are some macros available to do some special things as well. They are listed and described here: 

%doc is used to mark documentation in the source package that you want installed in a binary install. The documents will be installed in /usr/doc/$NAME-$VERSION-$RELEASE. You can list multiple documents on the command line with this macro, or you can list them all separately using a macro for each of them. 

%config is used to mark configuration files in a package. This includes files like sendmail.cf, passwd, etc. If you later uninstall a package containing config files, any unchanged files will be removed and any changed files will get moved to their old name with a .rpmsave appended to the filename. You can list multiple files with this macro as well. 

%dir marks a single directory in a file list to be included as being owned by a package. By default, if you list a directory name WITHOUT a %dir macro, EVERYTHING in that directory is included in the file list and later installed as part of that package. 

%defattr allows you to set default attributes for files listed after the defattr declaration. The attributes are listed in the form (mode, owner, group) where the mode is the octal number representing the bit pattern for the new permissions (like chmod would use), owner is the username of the owner, and group is the group you would like assigned. You may leave any field to the installed default by simply placing a - in its place, as was done in the mode field for the example package. 

%files -f «filename»will allow you to list your files in some arbitrary file within the build directory of the sources. This is nice in cases where you have a package that can build it's own filelist. You then just include that filelist here and you don't have to specifically list the files. 

Change Log
This is a log of what changes occurred when the package is updated. If you are modifying an existing RPM it is a good idea to list what changes you made here. The format is simple. Start each new entry with a line with a * followed by the date, your name, and your email address. The date should appear in the same format that is output by: 

date +"%a %b %d %Y"

 * Mon May 01 2000 John Hawk «visionary@gtemail.net»
- Added USB support

 The rest of the section is a free text field, but should be organized in some coherent manner.