There is a structure that has to be followed loosly
The Header of a spec
file
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 (ie. if we make a package and find it to be slightly broken and
need to make it again, the next package would be release number 2).
Icon: This is the name of the icon file for use by other
high level installation tools (like Red Hat's ``glint''). It must be a
gif and resides in the SOURCES directory.
Source: What file or files are being used 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
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. Caveat: The filename here must match the one you
use when you make YOUR patch. You may also want to note that you can have
multiple patch files much as you can have multiple sources. ] You would
have something like:
Patch0: blah-0.patch
Patch1: blah-1.patch
Patch2: fooblah.patch
These files would go in the SOURCES directory.
Copyright: This line tells how a package is copyrighted. You
should use something like GPL, BSD, MIT, public domain, distributable,
or commercial.
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.
Group: This line is used to tell high level installation programs
(such as Red Hat's ``glint'') where to place this particular program in
its hierarchical structure.
%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.
The %pre, %post, %preun, %postun script
The %pre script executes just before the package is to be installed. It is the rare package that requires anything to be done prior to installation; none of the 350 packages that comprise Red Hat Linux 4.0 make use of it.
The %post script executes after the package has been installed. One of the most popular reasons a %post script is needed is to run ldconfig to update the list of available shared libraries after a new one has been installed. Of course, other functions can be performed in a %post script. For example, packages that install shells use the %post script to add the shell name to /etc/shells.
If a package uses a %post script to perform some function, quite often it will include a %postun script that performs the inverse of the %post script, after the package has been removed.
If there's a time when your package needs to have one last look around before the user erases it, the place to do it is in the %preun} script. Anything that a package needs to do immediately prior to RPM taking any action to erase the package, can be done here.
The %postun script executes after the package has been removed. It is
the last chance for a package to clean up after itself. Quite often,
%postun scripts are used to run ldconfig to remove newly erased shared
libraries from ld.so.cache.