How to create a GNU Hello RPM package

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Building the package)
(s/f15/f19)
(38 intermediate revisions by 16 users not shown)
Line 1: Line 1:
Author: Przemek Klosowski
+
{{autolang|base=yes}}
 +
This is a short hands-on tutorial on writing RPM files, showing how to quickly step up to create simple source and binary software packages. It assumes some familiarity with using pre-made RPM packages, and with the FOSS software building process.
  
This is a short hands-on tutorial on writing RPM files, suitable for an impatient person who wants to quickly step up to create very simple source and binary software packages. I assume familiarity with using pre-made RPM packages, and with the FOSS software building process.  
+
For a comprehensive information on how to create RPM files, including more detailed tips, refer to [[How to create an RPM package]]. If you plan to create an RPM package for the Fedora repository, follow the process for [[Join the package collection maintainers|How to join the Fedora Package Collection Maintainers]], including following the various Fedora guidance.
  
For more information on how to create RPM files, including more detailed tips, see [[How to create an RPM package]].
+
This tutorial demonstrates packaging of the GNU "Hello World" project. While the C program printing 'Hello World" to standard output is trivial, the GNU version contains most of the usual peripheral components associated with a typical FOSS software project, including the configuration/build/install environment, documentation, internationalization, etc. The GNU version, however, traditionally consists of a tar file containing the source code and configure/make scripts, but it does not include the packaging information. Therefore, it's a reasonable vehicle to practice building RPMs on.
 
+
This tutorial demonstrates packaging of the GNU "Hello World" project. While 'Hello World" is a trivial program, the GNU project
+
contains most of the usual peripheral components associated with a typical FOSS software distribution,
+
including the configuration/build/install environment, documentation, internationalization, etc.  
+
As you will see, it's a reasonable vehicle to practice building RPMs on.
+
 
+
I wrote this tutorial when I worked through
+
[[Building_RPM_packages_%2820090405%29|Christoph Wickert's IRC class on building RPMs]] using Rahul Sundaram suggestion of GNU "Hello World" as a test case. After I wrote up my experience, I found out about the excellent and extensive
+
[[How to create an RPM package]] page on this wiki, as well as the
+
[http://www.absolutepanic.org/blog/2009/07/building-a-gnu-hello-world-rpm Christian Lyder Jacobsen's website].
+
However, Christian told me he isn't planning to update his
+
site, and I think a 5-minute 'fast food' alternative to the more
+
extensive article might suit some people.
+
More in-depth information on using and building RPM packages is available from [[Tools/RPM|other sources]].
+
  
 
== Development environment ==
 
== Development environment ==
  
To build RPMs we need a set of development tools. This is a one-time-only setup,
+
To build RPMs we need a set of development tools. This is a one-time-only setup, installed by running those commands from a system administration (<code>root</code>) account:
installed by running those commands from a system administration (<code>root</code>) account:
+
  
 
<pre>
 
<pre>
yum install @development-tools
+
# yum install @development-tools
yum install rpm-build rpmdevtools
+
# yum install fedora-packager
 
</pre>
 
</pre>
  
If you want to test the build procedure in the context of Fedora anonymous package build
+
If you want to test the build procedure in a clean chroot, you need to configure your non-privileged account to be a member of the 'mock' group:
system, you need to configure your non-privileged account to be a member of the 'mock' group:
+
 
 
<pre>
 
<pre>
usermod -a -G mock <your username>
+
# usermod -a -G mock <your username>
 
</pre>
 
</pre>
  
Those are the only commands requiring <code>root</code> privileges. All the remaining
+
Those are the only commands requiring <code>root</code> privileges. All the remaining work should be done from your regular, non-privileged account, or even from a separate account created just for development work. Modern RPM-based systems, including Fedora, are set up to build and test RPM packages purely from within a non-privileged account. The command
work should be done from your regular, non-privileged account, or even from a separate
+
account created just for development work. Modern RPM-based
+
systems, including Fedora, are set up to build and test RPM packages purely from
+
within a non-privileged account. The command  
+
  
<pre>rpmdev-setuptree</pre>
+
<pre>$ rpmdev-setuptree</pre>
  
sets up a RPM build
+
sets up a RPM build area in your <code>~/rpmbuild</code>. This directory will contain several subdirectories, for the project source code, RPM configuration files and for the resulting source and binary packages.
area in your <code>~/rpmbuild</code>. This directory will contain several subdirectories,  
+
for the project source code, RPM configuration files and for the resulting source and binary  
+
packages.
+
  
== Building a "Hello World" RPM==
+
== Building a "Hello World" RPM ==
  
 
We need the source code of the project we are packaging, often referred
 
We need the source code of the project we are packaging, often referred
Line 54: Line 33:
 
directory. We are getting the compressed tarball archive, which happens to be a preferred distribution form for  
 
directory. We are getting the compressed tarball archive, which happens to be a preferred distribution form for  
 
most FOSS projects.
 
most FOSS projects.
 +
 
<pre>
 
<pre>
cd ~/rpmbuild/SOURCE
+
$ cd ~/rpmbuild/SOURCES
wget http://ftp.gnu.org/gnu/hello/hello-2.5.tar.gz
+
$ wget http://ftp.gnu.org/gnu/hello/hello-2.8.tar.gz
 
</pre>
 
</pre>
  
 
The RPM package is configured by <code>.spec</code> files. We will create a template
 
The RPM package is configured by <code>.spec</code> files. We will create a template
 
file <code> hello.spec</code> in the appropriate directory:
 
file <code> hello.spec</code> in the appropriate directory:
 +
 
<pre>
 
<pre>
cd ~/rpmbuild/SPECS
+
$ cd ~/rpmbuild/SPECS
rpmdev-newspec hello
+
$ rpmdev-newspec hello
 
</pre>
 
</pre>
  
Recent versions of <code>Emacs</code> and <code>vi</code> have .spec file editing modes which will
+
Recent versions of <code>Emacs</code> and <code>vi</code> have .spec file editing modes which will also bring up a similar template upon creating a new file. So you can just use the following command for example to use the template automatically.
also bring up a similar template upon creating a new file. So you can just use the following command for example to use the template automatically.
+
  
 
<pre>
 
<pre>
 
 
vi hello.spec
 
vi hello.spec
 
 
</pre>
 
</pre>
  
 
=== Inside a <code>.spec</code> file ===
 
=== Inside a <code>.spec</code> file ===
  
The fields in our <code>.spec</code> file need slight editing. Please follow the
+
The fields in our <code>.spec</code> file need slight editing. Please follow the [[How_to_create_an_RPM_package#Spec_file_pieces_explained|Fedora rules]] for these fields. In our case, the file might start as follows:
[[How_to_create_an_RPM_package#Spec_file_pieces_explained|Fedora rules]]  
+
for these fields. In our case, the file might start as follows:
+
  
 
<pre>
 
<pre>
Name: hello
+
Name:     hello
Version: 2.5
+
Version: 2.8
Release: 1
+
Release: 1
Summary: The "Hello World" program
+
Summary: The "Hello World" program from GNU
License: GPLv3
+
License: GPLv3+
URL: http://ftp.gnu.org/gnu/hello     
+
URL:     http://ftp.gnu.org/gnu/hello     
Source0: http://ftp.gnu.org/gnu/hello/hello-2.5.tar.gz
+
Source0: http://ftp.gnu.org/gnu/hello/hello-2.8.tar.gz
%description:
+
 
 +
%description
 
The "Hello World" program, done with all bells and whistles of a proper FOSS  
 
The "Hello World" program, done with all bells and whistles of a proper FOSS  
project, including configuration, build, internationalization, helpfiles, etc.
+
project, including configuration, build, internationalization, help files, etc.
  
 
%changelog
 
%changelog
* Tue Mar 30 2010 The Coon of Ty <Ty@coon.org> 2.5-1
+
* Thu Jul 07 2011 The Coon of Ty <Ty@coon.org> - 2.8-1
 
- Initial version of the package
 
- Initial version of the package
 
 
</pre>
 
</pre>
  
The <code>Version</code> should mirror upstream while <code> Release</code> numbers our work
+
The <code>Version</code> should mirror upstream while <code> Release</code> numbers our work within Fedora.  
within Fedora.  
+
  
The first letter of the <code> Summary</code> should be uppercase to avoid
+
The first letter of the <code> Summary</code> should be uppercase to avoid rpmlint complaints.  
rpmlint complaints.  
+
  
It is your responsibility to check the <code>License</code> status of the software, by
+
It is your responsibility to check the <code>License</code> status of the software, by inspecting the source files and/or their LICENSE files, and/or by talking to the authors.
inspecting the source files and/or their LICENSE files, and/or by talking to the authors.
+
  
The <code> Group </code> tag is being phased out, but it doesn't hurt to classify it
+
The <code> Group </code> tag was historically used to classify the package in accordance to the list in <code>/usr/share/doc/rpm-<version>/GROUPS</code>. It is being phased out so you will not see it added by default. However, it doesn't hurt to add it anyway.
in accordance to the list in <code>/usr/share/doc/rpm-<version>/GROUPS</code>.
+
  
The <code> %changelog</code> should document the work on preparing the RPM , and should include the version string to avoid
+
The <code> %changelog</code> should document the work on preparing the RPM, especially if there are security and bug patches included on top of the base upstream source.  Changelog data can be displayed by <code>rpm --changelog -q <packagename></code>, which is very useful for instance to find out if specific bug and security patches were included in the installed software, thanks to diligent Fedora packagers who include this info with the relevant [http://cve.mitre.org/ CVE] numbers.
rpmlint complains.  
+
  
Multi-line sections like <code> %changelog</code> or <code> %description</code> start on a line under
+
The changelog entry should include the version string to avoid rpmlint complaints.
the directive, and end with an empty line.
+
 
 +
Multi-line sections like <code> %changelog</code> or <code> %description</code> start on a line under the directive, and end with an empty line.  
  
 
Lines which aren't needed (e.g. <code>BuildRequires</code> and <code>Requires</code>) can be commented out with a hash ('#') for now.
 
Lines which aren't needed (e.g. <code>BuildRequires</code> and <code>Requires</code>) can be commented out with a hash ('#') for now.
Line 126: Line 98:
  
 
<pre>
 
<pre>
rpmbuild -ba hello.spec
+
$ rpmbuild -ba hello.spec
 
</pre>
 
</pre>
  
It will complain and list the unpackaged files, i.e. the files that would be  
+
It will complain and list the unpackaged files, i.e. the files that would be installed in the system that weren't  declared as belonging to the package. We need to declare them in the <code>%files</code> section. Do not hardcode names like <code>/usr/bin/</code>, but use macros, like <code>%{_bindir}/hello</code> instead. The manual pages should be declared in the <code>%doc</code> subsection: <code>%doc %{_mandir}/man1/hello.1.gz</code>.
installed in the system that weren't  declared as belonging to the package. We need to declare them in the
+
<code>%files</code> section. Do not hardcode names like  
+
<code>/usr/bin/</code>, but use macros, like <code>%{_bindir}/hello</code> instead.
+
The manual pages should be declared in the <code>%doc</code> subsection:
+
<code>%doc %{_mandir}/man1/hello.1.gz</code>.
+
  
This is an iterative process: after editing the <code>.spec</code> file, rerun rpmbuild.
+
This is an iterative process: after editing the <code>.spec</code> file, rerun <code>rpmbuild</code>.
  
Since our program uses translations and internationalization, we are getting a lot of  
+
Since our program uses translations and internationalization, we are seeing a lot of undeclared i18 files. The [[Packaging:Guidelines#Handling_Locale_Files|recommended method]] to declare them is:
undeclared i18 files. The  
+
[[Packaging:Guidelines#Handling_Locale_Files|recommended method]]:
+
to declare them is:
+
  
* find the filenames in the <code>%install</code> step: <code> %find_lang ${name}</code>
+
* find the filenames in the <code>%install</code> step: <code> %find_lang %{name}</code>
 
* add the required build dependencies: <code>BuildRequires: gettext</code>
 
* add the required build dependencies: <code>BuildRequires: gettext</code>
* use the found filenames <code>%files -f ${name}.lang</code>
+
* use the found filenames <code>%files -f %{name}.lang</code>
  
If the program uses GNU info files, you need to make sure the installation and unistallation
+
If the program uses GNU info files, you need to make sure the installation and uninstallation
of the package does not interfere with other software on the system:
+
of the package does not interfere with other software on the system, by using this boilerplate:
  
* delete the 'dir' file in %install:  <code>rm -f $RPM_BUILD_ROOT/%{_infodir}/dir</code>
+
* delete the 'dir' file in %install:  <code>rm -f %{buildroot}/%{_infodir}/dir</code>
 
* <code>Requires(post): info</code> and <code>Requires(preun): info</code>
 
* <code>Requires(post): info</code> and <code>Requires(preun): info</code>
 
* add those steps:
 
* add those steps:
Line 169: Line 133:
 
<pre>
 
<pre>
 
Name:          hello
 
Name:          hello
Version:        2.5
+
Version:        2.8
 
Release:        1%{?dist}
 
Release:        1%{?dist}
Summary:        The "hello world" program from GNU
+
Summary:        The "Hello World" program from GNU
  
Group:          Applications/Text
+
License:        GPLv3+
License:        GPLv3
+
URL:            http://ftp.gnu.org/gnu/%{name}
URL:            http://ftp.gnu.org/gnu/hello
+
Source0:        http://ftp.gnu.org/gnu/%{name}/%{name}-%{version}.tar.gz
Source0:        http://ftp.gnu.org/gnu/hello/hello-2.5.tar.gz
+
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+
  
 
BuildRequires: gettext
 
BuildRequires: gettext
# Requires:        
+
        
 
Requires(post): info
 
Requires(post): info
 
Requires(preun): info
 
Requires(preun): info
  
 
%description  
 
%description  
The "hello world" program from GNU, with bells and whistles
+
The "Hello World" program, done with all bells and whistles of a proper FOSS
 
+
project, including configuration, build, internationalization, help files, etc.
  
 
%prep
 
%prep
 
%setup -q
 
%setup -q
 
  
 
%build
 
%build
 
%configure
 
%configure
 
make %{?_smp_mflags}
 
make %{?_smp_mflags}
 
  
 
%install
 
%install
rm -rf $RPM_BUILD_ROOT
+
%make_install
make install DESTDIR=$RPM_BUILD_ROOT
+
 
%find_lang %{name}
 
%find_lang %{name}
rm -f $RPM_BUILD_ROOT%{infodir}/dir
+
rm -f %{buildroot}/%{_infodir}/dir
  
 
%post
 
%post
Line 210: Line 169:
 
/sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
 
/sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
 
fi
 
fi
 
%clean
 
rm -rf $RPM_BUILD_ROOT
 
 
  
 
%files -f %{name}.lang
 
%files -f %{name}.lang
%defattr(-,root,root,-)
+
%doc AUTHORS ChangeLog COPYING NEWS README THANKS TODO
 +
%{_mandir}/man1/hello.1.gz
 +
%{_infodir}/%{name}.info.gz
 
%{_bindir}/hello
 
%{_bindir}/hello
%doc %{_mandir}/man1/hello.1.gz
 
%doc %{_infodir}/%{name}.info.gz
 
  
 
%changelog
 
%changelog
* Tue Mar 30 2010 The Coon of Ty <Ty@coon.org> 2.5-1
+
* Tue Sep 06 2011 The Coon of Ty <Ty@coon.org> 2.8-1
 
- Initial version of the package
 
- Initial version of the package
 
</pre>
 
</pre>
  
With this spec file, you should be able to successfully complete the
+
With this spec file, you should be able to successfully complete the build process, and create the source and binary RPM packages.  
build process, and create the source and binary RPM packages.  
+
  
Next you should check them for conformance with RPM design
+
Next you should check them for conformance with RPM design rules, by running <code>rpmlint</code> on the spec file and all RPMs:  
rules, by running <code>rpmlint</code> on the spec file and all RPMs:  
+
  
 
<pre>
 
<pre>
rpmlint hello.spec ../SRPMS/hello* ../RPMS/*/hello*
+
$ rpmlint hello.spec ../SRPMS/hello* ../RPMS/*/hello*
 
</pre>
 
</pre>
  
If there are no warnings or errors, we've succeeded. Otherwise,  
+
If there are no warnings or errors, we've succeeded. Otherwise, use <code>rpmlint -i</code> or <code>rpmlint -I &lt;error_code&gt;</code> to see a more verbose description of the <code>rpmlint</code> diagnostics.
append the error messages to the <code>rpmlint -I</code>  
+
command to see a more verbose description of the <code>rpmlint</code> diagnostics.
+
  
 
=== The <code>mock</code> builds ===
 
=== The <code>mock</code> builds ===
  
To check that the package build will succeed in the Fedora restricted
+
To check that the package build will succeed in the Fedora restricted build environment, check it with mock.  The default mock configuration builds the package against Rawhide - the Fedora development branch.
build environment, check it with mock.
+
  
 
<pre>
 
<pre>
mock -r fedora-12-i386 --rebuild ../SRPMS/hello-2.5-1.fc12.src.rpm
+
$ mock --verbose ../SRPMS/hello-2.7-1.fc19.src.rpm
 
</pre>
 
</pre>
 +
 +
== References ==
 +
 +
* [[How to create an RPM package]]
 +
* [[Building RPM packages (20090405)]]
 +
* [[Using Mock to test package builds]]
 +
* [[Using the Koji build system]]
 +
 +
== History ==
 +
 +
Przemek Klosowski wrote this tutorial when he worked through [[Building_RPM_packages_%2820090405%29|Christoph Wickert's IRC session on building RPMs]] using Rahul Sundaram suggestion of GNU "Hello World" as a test case. After he wrote up his experience, he found out about the excellent and extensive [[How to create an RPM package]] page on this wiki, as well as the [http://www.absolutepanic.org/blog/2009/07/building-a-gnu-hello-world-rpm Christian Lyder Jacobsen's website]. However, Christian isn't planning to update his site, and it seemed that a 5-minute 'fast food' alternative to the more extensive article might suit some people. More in-depth information on using and building RPM packages is available from [[Yum|other sources]].
 +
 +
[[Category:Package Maintainers]][[Category:How to]]

Revision as of 15:40, 24 April 2013

This is a short hands-on tutorial on writing RPM files, showing how to quickly step up to create simple source and binary software packages. It assumes some familiarity with using pre-made RPM packages, and with the FOSS software building process.

For a comprehensive information on how to create RPM files, including more detailed tips, refer to How to create an RPM package. If you plan to create an RPM package for the Fedora repository, follow the process for How to join the Fedora Package Collection Maintainers, including following the various Fedora guidance.

This tutorial demonstrates packaging of the GNU "Hello World" project. While the C program printing 'Hello World" to standard output is trivial, the GNU version contains most of the usual peripheral components associated with a typical FOSS software project, including the configuration/build/install environment, documentation, internationalization, etc. The GNU version, however, traditionally consists of a tar file containing the source code and configure/make scripts, but it does not include the packaging information. Therefore, it's a reasonable vehicle to practice building RPMs on.

Contents

Development environment

To build RPMs we need a set of development tools. This is a one-time-only setup, installed by running those commands from a system administration (root) account:

# yum install @development-tools
# yum install fedora-packager

If you want to test the build procedure in a clean chroot, you need to configure your non-privileged account to be a member of the 'mock' group:

# usermod -a -G mock <your username>

Those are the only commands requiring root privileges. All the remaining work should be done from your regular, non-privileged account, or even from a separate account created just for development work. Modern RPM-based systems, including Fedora, are set up to build and test RPM packages purely from within a non-privileged account. The command

$ rpmdev-setuptree

sets up a RPM build area in your ~/rpmbuild. This directory will contain several subdirectories, for the project source code, RPM configuration files and for the resulting source and binary packages.

Building a "Hello World" RPM

We need the source code of the project we are packaging, often referred to as the 'upstream' source. We will download it from the project's website into the ~/rpmbuild/SOURCE directory. We are getting the compressed tarball archive, which happens to be a preferred distribution form for most FOSS projects.

$ cd ~/rpmbuild/SOURCES
$ wget http://ftp.gnu.org/gnu/hello/hello-2.8.tar.gz

The RPM package is configured by .spec files. We will create a template file hello.spec in the appropriate directory:

$ cd ~/rpmbuild/SPECS
$ rpmdev-newspec hello

Recent versions of Emacs and vi have .spec file editing modes which will also bring up a similar template upon creating a new file. So you can just use the following command for example to use the template automatically.

vi hello.spec

Inside a .spec file

The fields in our .spec file need slight editing. Please follow the Fedora rules for these fields. In our case, the file might start as follows:

Name:     hello
Version:  2.8
Release:  1
Summary:  The "Hello World" program from GNU
License:  GPLv3+
URL:      http://ftp.gnu.org/gnu/hello    
Source0:  http://ftp.gnu.org/gnu/hello/hello-2.8.tar.gz

%description
The "Hello World" program, done with all bells and whistles of a proper FOSS 
project, including configuration, build, internationalization, help files, etc.

%changelog
* Thu Jul 07 2011 The Coon of Ty <Ty@coon.org> - 2.8-1
- Initial version of the package

The Version should mirror upstream while Release numbers our work within Fedora.

The first letter of the Summary should be uppercase to avoid rpmlint complaints.

It is your responsibility to check the License status of the software, by inspecting the source files and/or their LICENSE files, and/or by talking to the authors.

The Group tag was historically used to classify the package in accordance to the list in /usr/share/doc/rpm-<version>/GROUPS. It is being phased out so you will not see it added by default. However, it doesn't hurt to add it anyway.

The  %changelog should document the work on preparing the RPM, especially if there are security and bug patches included on top of the base upstream source. Changelog data can be displayed by rpm --changelog -q <packagename>, which is very useful for instance to find out if specific bug and security patches were included in the installed software, thanks to diligent Fedora packagers who include this info with the relevant CVE numbers.

The changelog entry should include the version string to avoid rpmlint complaints.

Multi-line sections like  %changelog or  %description start on a line under the directive, and end with an empty line.

Lines which aren't needed (e.g. BuildRequires and Requires) can be commented out with a hash ('#') for now.

Many lines in the template don't need to be changed at all in many cases, at least for the initial attempt.

Building the package

We are ready for the first run to build source, binary and debugging packages:

$ rpmbuild -ba hello.spec

It will complain and list the unpackaged files, i.e. the files that would be installed in the system that weren't declared as belonging to the package. We need to declare them in the %files section. Do not hardcode names like /usr/bin/, but use macros, like %{_bindir}/hello instead. The manual pages should be declared in the %doc subsection: %doc %{_mandir}/man1/hello.1.gz.

This is an iterative process: after editing the .spec file, rerun rpmbuild.

Since our program uses translations and internationalization, we are seeing a lot of undeclared i18 files. The recommended method to declare them is:

  • find the filenames in the %install step:  %find_lang %{name}
  • add the required build dependencies: BuildRequires: gettext
  • use the found filenames %files -f %{name}.lang

If the program uses GNU info files, you need to make sure the installation and uninstallation of the package does not interfere with other software on the system, by using this boilerplate:

  • delete the 'dir' file in %install: rm -f %{buildroot}/%{_infodir}/dir
  • Requires(post): info and Requires(preun): info
  • add those steps:
%post
/sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || :

%preun
if [ $1 = 0 ] ; then
/sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
fi

A complete hello.spec file

Here's the initial version of hello.spec:

Name:           hello
Version:        2.8
Release:        1%{?dist}
Summary:        The "Hello World" program from GNU

License:        GPLv3+
URL:            http://ftp.gnu.org/gnu/%{name}
Source0:        http://ftp.gnu.org/gnu/%{name}/%{name}-%{version}.tar.gz

BuildRequires: gettext
      
Requires(post): info
Requires(preun): info

%description 
The "Hello World" program, done with all bells and whistles of a proper FOSS 
project, including configuration, build, internationalization, help files, etc.

%prep
%setup -q

%build
%configure
make %{?_smp_mflags}

%install
%make_install
%find_lang %{name}
rm -f %{buildroot}/%{_infodir}/dir

%post
/sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || :

%preun
if [ $1 = 0 ] ; then
/sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
fi

%files -f %{name}.lang
%doc AUTHORS ChangeLog COPYING NEWS README THANKS TODO
%{_mandir}/man1/hello.1.gz
%{_infodir}/%{name}.info.gz
%{_bindir}/hello

%changelog
* Tue Sep 06 2011 The Coon of Ty <Ty@coon.org> 2.8-1
- Initial version of the package

With this spec file, you should be able to successfully complete the build process, and create the source and binary RPM packages.

Next you should check them for conformance with RPM design rules, by running rpmlint on the spec file and all RPMs:

$ rpmlint hello.spec ../SRPMS/hello* ../RPMS/*/hello*

If there are no warnings or errors, we've succeeded. Otherwise, use rpmlint -i or rpmlint -I <error_code> to see a more verbose description of the rpmlint diagnostics.

The mock builds

To check that the package build will succeed in the Fedora restricted build environment, check it with mock. The default mock configuration builds the package against Rawhide - the Fedora development branch.

$ mock --verbose ../SRPMS/hello-2.7-1.fc19.src.rpm

References

History

Przemek Klosowski wrote this tutorial when he worked through Christoph Wickert's IRC session on building RPMs using Rahul Sundaram suggestion of GNU "Hello World" as a test case. After he wrote up his experience, he found out about the excellent and extensive How to create an RPM package page on this wiki, as well as the Christian Lyder Jacobsen's website. However, Christian isn't planning to update his site, and it seemed that a 5-minute 'fast food' alternative to the more extensive article might suit some people. More in-depth information on using and building RPM packages is available from other sources.