gleblanc@cu-portland.edu
This document attempts to outline the guidelines that GPP spec files should adhere to. These guidelines are designed to make spec files that will function on at least Red Hat 6.x and 7.x. They should also function on Red Hat-like systems with only minor adjustments. For systems that use RPM but aren't Red Hat-like, these spec files should serve as a good starting point.
Some knowledge of writing RPM spec files is assumed. The book Maximum RPM has a good intro to some of the concepts and syntax used in RPM spec files.
The first section of the spec file is the preamble. This contains lots of general information about the package, such as the name, version, source location, and so on. Since the GNOME project uses autoconf and automake to help ensure that our programs are portable, we've tried to leverage this into our spec files. We use autoconf to replace the version number, and to help up manage package dependancy versions.
localstatedir. This line forces localstatedir to be set to /var/lib. This directory isn't set to FHS compliance by RPM, so we're forced to override it here.
Summary. This should be a short summary of what the program or package does. Including the name of the package here is redundant, so don't do that.
Name. This specified the name of the package. It is case-sensitive, and should match the name of the tarball created when you run 'make dist'.
License. This is the license that the package is distributed under. Probably GPL or LGPL for most GNOME packages. Many older spec files erroneously call this field "Copyright". Please correct this when you see it.
Group. This should be one of the canonical groups from /usr/share/doc/rpm-VERSION/GROUPS. Please don't make up new groups.
Source. You can have multiple "Source" lines. You should start numbering sources at 0. A tag of simply "Source" implies 0. You should include a complete URL to the source package whenever possible.
BuildRoot. Make sure you use the special %{_tmppath} macro, and not hardcode /tmp or /var/tmp. The user may have configured RPM to put temporary files elsewhere. Use the name and version macros so that you can build two different versions of the package at the same time without collisions.
URL. Use this tag for the package's homepage, if it has one.
PreReq. This lists files or packages that are required to be present before the package can be installed. This is very important if you're using other programs in %pre or %post sections.
Requires. If this package requires other packages to be installed in order to function properly, they should be listed here. Note the @GTK_REQUIRED@, which is defined in configure.in. This ensures that the version required by the configure script is the same as the version required by RPM. You can specify files here by their full path, for example /sbin/ldconfig.
BuildRequires. This is similar to the PreReq tag, except that it applies to the build of this package. So, if the package needs some other package installed the time that configure is run, it should be listed on the BuildRequires line