As stated in the last part, it’s now time to build the first RPM. The first RPM only has one purpose, it should create the environment for further RPMs with the same domain. The central file for creating RPMs is the so-called SPEC file. The SPEC file defines the content of the package, the metadata for the package as well as pre-, post- and all other activities required to install the package. The format of the SPEC file is pretty unique, I’m not aware of any close match with other configuration file formats. The second important file is the SOURCE file. This is a classic tar file that contain usually the binaries, libraries and so forth that are required to run the program. Larger software packages are often separated into multiple RPMs to allow a modular installation.
So. let’s start with the SPEC file. The first part describes the package metadata:
%define debug_package %{nil}
Summary: SAP common
Name: sap-common
Version: 1.2
Release: 0%{?dist}
License: GPL-3.0
Group: Applications/Productivity
URL: %{url}
Packager: %{packager}
Vendor: %{vendor}
BuildArch: noarch
BuildRoot: %{_tmppath}/%{name}-buildroot
%description
This package contains the basic file layout for sap rpms provided by thbe
The head options are quite self-explaining. What is this package about, who owns the package, which license is used, what version, where it belongs to, and so forth? In the next part I will showcase a bit more complex header in the SPEC file.
%prep
%build
The next two sections are not used within this technically simple first RPM. The prep section is used for commands, scripts and the like to prepare the installation whereas the build section is used to build software from the source.
%install
rm -rf $RPM_BUILD_ROOT
install -m 0755 -d $RPM_BUILD_ROOT/etc/opt/sap/
install -m 0755 -d $RPM_BUILD_ROOT/opt/sap/
install -m 0755 -d $RPM_BUILD_ROOT/opt/sap/exe
%clean
rm -rf $RPM_BUILD_ROOT
The install and clean sections are used to build the RPM. In this case, the package would like to be owner of three directories. It should own the root directory for all SAP RPMs I build. This means, every package I build uses sap-common as a requirement and will story its binaries somewhere underneath /opt/sap (more to come in the next part). It should additionally own the central configuration directory and own a directory to link executables.
%post
Another, not used section, is the post section. This is used if actions need to be performed after an RPM is installed, for example, activating a service.
%files
%defattr(-, root, root, 755)
%dir /etc/opt/sap
%dir /opt/sap
%dir /opt/sap/exe
After the install section has built the package, the files section ensures that the content is registered correctly in the RPM database. This is where all RPMs register their content so that the system gets a holistic view of the state of all package installations.
%changelog
* Fri Dec 04 2015 Thomas Bendler <code@thbe.org> 1.2-0
- Add config directory for SAP relevant files
* Fri Oct 16 2015 Thomas Bendler <code@thbe.org> 1.1-3
- Fix directory permissions
* Thu Jul 07 2011 Thomas Bendler <code@thbe.org> 1.1-2
- Version fixes
* Wed Jul 06 2011 Thomas Bendler <code@thbe.org> 1.1
- Added exe directory for sapcar RPM
* Mon Nov 22 2010 Thomas Bendler <code@thbe.org> 1.0
- Initial release
The last section is the package-specific changelog. All changes to this package can/ should be tracked in the changelog. Nowadays this become a slightly duplicate work as most changes are tracked already in the git repository. This can be mitigated, for example, by using releases in git and using the link to the release in the changelog.
Note: Like with nearly every software project, it’s a good practice to use a linter after the SPEC file has been written to ensure it’s syntactically correct.
Building RPM packages: