How-To Create a blackPanther RPM

blackPanther RPMS Packaging is a cool feature when you want to have a software easily installed on different machines. On top of that, it is easier to manage installed packages, remove them or update them.

This How-To will explain how to create a distributable package using rpmbuild package. This tutorial was done on a blackPanther OS 10.x machine but should be working on all blackPanther OS releases

For the purpose of this tutorial, we are going to package example2

This tutorial will consist in preparing your machine, get the source, create magical .spec file and finally compile the package.

1. installing the necessary packages

First of all, in order to be able to build a package, we need to have the rpmbuild executable. In order to get it, we need to install rpm-build. As root type:

# installing rpm-build

After install the packages created the following directories in /usr/src/RPM:
BUILD RPMS SOURCES SPECS SRPMS

The different directories will be used for:
BUILD : The place where rpmbuild will build the package
RPMS : The binary package created by rpmbuild will be stored here
SOURCES : The place where to keep the original software sources
SPECS : This is where the .spec will be stored
SRPMS : The source rpm from your build will be stored there

If you want make RPM by user we need to create a directory structure which is going to host the different elements that are required when building an RPM. As a normal user, type:

$ mkdir ~/rpmbuild
$ cd ~/rpmbuild
$ mkdir BUILD RPMS SOURCES SPECS SRPMS

2. creating the package

2.1. getting the sources
In the first place, we need to get the software source available on our system. As said earlier, the directory to host the sources is: SOURCES ;), therefore we are going to cd to this directory and download the source there.

$ cd ~/rpmbuild/SOURCES/
$ wget http://www.blackpantheros.eu/~vector/src/doc/example2-1.0.tar.bz2

Now, we have our source, let’s go and create our spec file.

2.2. the .spec file
The .spec is the file holding the information on how-to build the package. This file will contain section for unpacking the sources, building them, installing, removing the files. It will also contains meta-information on the software such as the version, the dependencies ….

Let’s go to the SPECS directory and get our .spec file (this easy simple spec file):
cd ~/rpmbuild/SOURCES/
wget http://www.blackpantheros.eu/~vector/src/doc/example.spec

This is it, this .spec file contains all the information required to create an RPM from the sources. Let go through this file to get a better understanding of what’s happening. The official full featured SPEC are available here

2.3. inside .spec file

Let’s get through this file. The best way to create your own will be to use this one as a template and adapt it to your need.

This file basically contains 7 sections: introduction, prep, build, install, clean, files and changelog. I will go through each section individually.

2.3.1. introduction section

the first section, up to %prep is pretty explicit by itself. It mainly contains information as seen by rpm -qi subtitleeditor. Here is a short description of each parameters:

  • Summary: a short description of the package
  • Name: the name of the package
  • Version: the version of the package we are building. Here subtitleeditor-0.20.0alpha4
  • Release: the package release number. Here 1.rb7
  • License: the license under which the software is released, here GPL
  • Group: the group your package belongs to. See /usr/share/doc/rpm-/GROUPS
  • URL: software homepage
  • Source: the location of the sources
  • BuildRoot: where the package is going to be built
  • Patch: if you need to apply patch, enter the patch file name and copy the file to the SOURCES directory
  • BuildRequires: packages requires in order to build this packages
  • Packager: the name of the packager
  • %description: a longer description of the package

Once the package introduced, we need to define how to build the package.

2.3.2. prep section

The prep section prepares the package for the build process. This is the section taking care of untarring the package as well as patching if required.

%setup -q is a rpm macro which knows how to unarchive the source.
%patch will patch the source tree.

2.3.3. build section

This section will configure and make the package. Here we use the %configure to which we append the –disable-debug as we don’t want to compile this feature.
Then we compile the package with the %{__make} macro.

The meaning of the macros can be found in /etc/rpm/macros and macros.d

2.3.4. install section

This section take care of cleaning up the BuildRoot and installing the application.

2.3.5. clean section

Cleans up files created by other sections.

2.3.6. files section

defines the files that have to go in the binary RPM. Permission are defined and special attributes can be used.

This section starts with %files, additionally, the list of files that have to be included can be in a separate file, here subtitleeditor.lang.

%defattr(-, root, root, 0755) define the file attributes.

Files can be marked as document files by prepending their name with %doc.

You can exclude a file from a package using the %exclude macro.

2.3.7. changelog section

Finally the last section: %changelog.

You should add a new changelog entry anytime you repackage the RPM. Changelogs entry are defined as:

* Date - email name
- Action taken

Well, now that we have defined how to build our package, let’s build it!

2.4. building the package

Finally, we are ready do get our first package built!!!.

At this point, in ~/packages we can see the directories:

$ ls ~/rpmbuild/
BUILD RPMS SOURCES SPECS SRPMS

SPECS contains example spec file, SOURCES contains our source tarball and eventually, patches.

Let’s go do our SPECS directory and start building our package.

$ cd ~/rpmbuild/SPECS

In order to build a package, we are going to use the rpmbuild command.

rpmbuild syntax is: rpmbuild -b<build stage> <spec file>. So, depending on which build stage you choose, you are going to build either th binary RPM, source RPM, none of them or both of them. Here is the list of the different switches that can be used:

  • -ba : build all, both a binary and source RPM
  • -bb : build only the binary RPM
  • -bc : only compile the program. Does not make the full RPM, stopping just after the %build section
  • -bp : prepare for building a binary RPM, and stop just after the %prep section
  • -bi : create a binary RPM and stop just after the %install section
  • -bl : check the listing of files for the RPM and generate errors if the buildroot is missing any of the files to be installed
  • -bs : build aonly the source RPM

Therefore, if you want to build everything (source RPM, binary RPM), you will type:

$ rpmbuild -ba example.spec

if you only want to build the binary RPM:

$ rpmbuild -bb example.spec

will do.

Unfortunately, this is not going to work on the first shot because we are not building the package into the default location: /usr/src/RPM. In order to tell rpmbuild to use another top directory, we are going to use a rpm macrorpm macros can be set in ~/.rpmmacros. Open and edit ~/.rpmmacros with the following line:

%_topdir /home/<your user here>/packages

Now, when you will use rpmbuild, /home/user/packages will be used as the top directory.

What to expect from now? Running:

$ rpmbuild -ba subtitleeditor.spec

Should unpack the archive, configure, compile and install the software into an rpm package. The source RPM will be in ~/packages/SRPMS while the binary RPM will be in ~/packges/RPMS/ … If rpmbuild did not end up on an error ;).

Well, that’s it, if everything when without error, you have your RPM package ready in ~/packages/RPMS// , you can now distribute this package and you will be able to manage it with your package manager.

2.5. signing your packages

Signing a RPM with rpmbuild is pretty easy. First, you need to have a GPG key. I suppose that you already have a GPG key. Please read this: RPM packages with my GPG key

3. conclusion

By using a template .spec, it is pretty easy to create your own package. Once packaged, the software will be easier to distribute, install, uninstall and manage.

There is a lot more you can do with the .spec file, but this is out of the scope of this article.

Let’s start packaging 😉

This page is a Wiki! Log in or register an account to edit.
admin

About admin