This exercise will teach you:
1. What is an spec file and how it is formed
2. How to write the spec file
3. How to check the spec file builds correctly
The spec file is at the heart of the package. It contains information required to build the package, instructions on how to build it and it dictates exactly what files are a part of the package, and where they should be installed.
With this many responsibilities, the spec file format can be a bit complex. However, it's broken into several sections, most of them being shell scripts, making it easier to handle. All told, there are seven sections:
1. preamble 2. prep 3. build 4. install 5. clean 6. files 7. changelog
The preamble contains information that will be displayed when users request information about the package. This would include a description of the package's function, the version number of the software, and so on. Also contained in the preamble are lines identifying sources, patches, and more.
The prep section is where the actual work of building a package starts. As the name implies, this section is where the necessary preparations are made prior to the actual building of the software. In general, if anything needs to be done to the sources prior to building the software, it needs to happen in the prep section. Usually, this boils down to unpacking the sources.
The build section is used to perform whatever commands are required to actually compile the sources. This section usually consists of a single make command, but it can be more complex if the building process needs it.
The files section is a list of files and where this files must go, this will be the package and this section is very important. A number of macros can be used to control file attributes when installed, as well as to denote which files are documentation, and which contain configuration information.
Write the spec file (from the empty template) using your favorite editor, in this example vim.
$ vim my_packages/base.spec
You will see the sections explained above. Writing a spec file can be as simple as filling those sections. But since this is your first one, close vim and let's give you an example...
%include Solaris.inc
Name: nano
Summary: GNU nano text editor
Version: 2.0.9
License: GPLv2
Url: http://www.nano-editor.org
Source: http://www.nano-editor.org/dist/v2.0/%{name}-%{version}.tar.gz
Group: Editor
Distribution: OpenSolaris
Vendor: OpenSolaris Community
BuildRoot: %{_tmppath}/%{name}-%{version}-build
SUNW_Basedir: %{_basedir}
SUNW_Copyright: %{name}.copyright
%include default-depend.inc
# OpenSolaris IPS Manifest Fields
Meta(info.upstream): Chris Allegretta
Meta(info.maintainer): Peter Jones
Meta(info.repository_url): svn://svn.sv.gnu.org/nano/trunk/nano/
%description
GNU nano is an effort to provide a Pico-like editor, but also includes some features that
were missing in the original, such as 'search and replace', 'goto line' or internationalization
support.
We define name, license, version, url and description that will appear when the package is searched or package information triggered. The IPS build system will download the tarball defined in source, and will build from it. Notice the nano.copyright file in the copyright directory. Packages won't build if there is no copyright file for them.
%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
rm -f $RPM_BUILD_ROOT%{_infodir}/dir
Any previous builds are removed. Package is built and installed in the buildroot with make install. The files that don't need to be installed are removed from the buildroot.
In this page, you have learned the format of an IPS spec file, how it works and how to write one looking at an example spec file.
Did you see how easy it was?
Go write yours now! :)
Use at Own Risk: As provided in the Web Site Terms of Use,
the Hosts may or may not pre-screen or perform compatibility testing on the Materials,
and by using this repository You agree to assume all risks in Using the Materials.
These risks include, but are not limited to, errors, viruses, worms, time-limited
software that expires without notice, defamatory or offensive content, and the
possibility that the Materials infringe or misappropriate the intellectual property
rights of others.