Chris Tyler - Fedora Linux

There are two advantages to placing the files into the BuildRoot instead of the final file location: the Fedora system you're using won't get messed up, and since the only files that should be in the BuildRoot are those installed by this package, you can check to see that you can account for all of them.

The %install section often consists of an rm command to clear out the BuildRoot , followed by the %makeinstall macro to run make install with the appropriate options to install into BuildRoot instead of the root directory (most, but not all, modern open source packages will respect these options). The whole %install section looks like this:

%install

rm -rf %{buildroot}

%makeinstall

If you leave out the %check section (which is optional), the next section is %clean commands to clean up the BuildRoot . This is usually the same rm command that was used in the %install section:

%clean

rm -rf %{buildroot}

At this point, the whole spec file looks like this:

Name: CriticalMass

Version: 1.0.0

Release: 1

Group: Amusements/Games

Summary: An arcade-style shoot-em-up game.

License: GPL

Source0: CriticalMass-1.0.0.tar.bz2

URL: http://sourceforge.net/projects/criticalmass

BuildRoot: %{_tmppath}/%{name}-root

%description

CriticalMass is an old-style arcade-style shoot-em-up game with

modern graphics and sound.

%prep

%setup

%build

%configure

make %{_smp_mflags}

%install

rm -rf %{buildroot}

%makeinstall

%clean

rm -rf %{buildroot}

This file is saved in ~/rpm/CriticalMass/CriticalMass.spec . Note that the %prep , %build , %install , and %clean sections are pretty generic and could be used with many different packages.

The next section required is a list of files to be included in the package. The easy way to prepare this list is to have rpmbuild the RPM package-building toolbuild the package and install it into the BuildRoot , and then see what's there:

$ cd ~/rpm/ CriticalMass

$ ls

CriticalMass-1.0.0.tar.bz2 CriticalMass.spec

$ rpmbuild -bi CriticalMass.spec

Executing(%prep): /bin/sh -e /home/chris/rpm/tmp/rpm-tmp.54511

+ umask 022

+ cd /home/chris/rpm/tmp

+ LANG=C

...(Lines snipped)...

Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/chris/rpm/tmp/CriticalMass-root

error: Installed (but unpackaged) file(s) found:

/usr/bin/Packer

/usr/bin/critter

/usr/share/Critical_Mass/lg-criti.xm

/usr/share/Critical_Mass/resource.dat

/usr/share/man/man6/critter.6.gz

RPM build errors:

Installed (but unpackaged) file(s) found:

/usr/bin/Packer

/usr/bin/critter

/usr/share/Critical_Mass/lg-criti.xm

/usr/share/Critical_Mass/resource.dat

/usr/share/man/man6/critter.6.gz

If your build fails because you need additional software, you must find that software and add it to a BuildRequires line in the spec file.

The -bi argument to rpmbuild instructs it to build up to the end of the %install stage. You can see that rpmbuild has detected files in BuildRoot that are not included in the package. To see the actual contents of the BuildRoot , you can change to the ~/rpm/CriticalMass directory and look around:

$ cd ~/rpm/tmp/ CriticalMass -root

$ find

.

./usr

./usr/bin

./usr/bin/Packer

./usr/bin/critter

./usr/lib

./usr/lib/debug

./usr/lib/debug/usr

./usr/lib/debug/usr/bin

./usr/lib/debug/usr/bin/critter.debug

./usr/lib/debug/usr/bin/Packer.debug

./usr/share

./usr/share/man

./usr/share/man/man6

./usr/share/man/man6/critter.6.gz

./usr/share/Critical_Mass

./usr/share/Critical_Mass/resource.dat

./usr/share/Critical_Mass/lg-criti.xm

./usr/src

./usr/src/debug

The find command recursively lists all of the files found in the current directory.

From this list of files, you can build the %files section of the spec file. You can safely ignore the files in /usr/lib/debug and /usr/src since the RPM system will package these up into a separate debug RPM package automatically.

Among these files, there are some binaries:

./usr/bin/Packer

./usr/bin/critter

There is also a manpage:

./usr/share/man/man6/critter.6.gz

plus a data directory and some datafiles:

./usr/share/Critical_Mass

./usr/share/Critical_Mass/resource.dat

./usr/share/Critical_Mass/lg-criti.xm

The /usr/share/CriticalMass directory belongs to the package and should be removed when the package is removed. To configure this, you must list only the directory in the %files section of the spec file; the contents of the directory will automatically be included.

Other directories, such as /usr/bin and /usr/share/man/man6 , also contain files belonging to other packages, so those directories must not be included in the %files list; only the individual files in those directories should be included.

Because the RPM package is being built by a regular useryou or meand our accounts may not exist on the target machine, you must reassign the ownership (and possibly the permissions) of the files using the %defattr directive. %defattr accepts four arguments: the default permission for files, the owner, the group, and the default permission for directories. Use a hyphen for permissions to signify that the existing file permissions should be left untouched:

%defattr(-, root, root, -)

To set specific attributes for a specific file, use %attr with three arguments (permission, user, group):

%defattr(0511, root, nogroup) foofile

In addition to files in the BuildRoot , you should also identify files in the top-level directory of the tarball that should be included in the file as documentation; this is done using the %doc directive. When the package is installed, these files will be placed in /usr/share/doc/ . Good candidates for documentation files include README , TODO , BUGS , INSTALL , COPYING , and any other notes the program author has provided. In the case of the CriticalMass software, only the files COPYING and TODO fit into this category:

%doc COPYING TODO

In a similar way, the %config directive specifies configuration files that are included in the RPM:

%config /etc/master.conf