RPM PackagesIn this blog, we’ll look at how to manually build Percona Server for MySQL RPM packages.

Several customers and other people from the open source community have asked us how they could make their own Percona Server for MySQL RPM binaries from scratch.

This request is often made by companies that want to add custom patches to our release. To do this, you need to make some modifications to the percona-server.spec file in the source tree, and some preparation is necessary.

This post covers how you can make your own RPMs from GIT or source tarball so that you can build RPMs from your own modified branch, or by applying patches. In this example, we’ll build Percona Server 5.7.16-10.

Making your own RPMs is not a recommended practice, and should rarely be necessary.

Prepare the Source

Using GIT Repository

We can fetch percona/percona-server from GitHub (or your own fork). As we build Percona Server 5.7.16-10, we create a new branch based on the tag of that version:

Downloading Source Tarball

An alternative way is to download the source tarball, which you can find at https://www.percona.com/downloads/Percona-Server-5.7/Percona-Server-5.7.16-10/source/.

Extract the source tarball, as the RPM spec file is located there:

Making Changes with Patch Files

If you need to make any changes to the source code, you can either use your own GitHub fork or you can apply patches. If you use the former, then you can skip this section.

Why Patches?

Why would we want to use patch files? Because you won’t need to maintain your own fork. You can just build the RPM with the Percona Server source tarball and the patch file.

Create Patch Files

If you do not want to use your own fork in GitHub, you can also create some patch files and modify the RPM spec file to include them.

  1. Create your changes to the source files
  2. Use diff to create the patch file:

Add Patch to RPM Spec File

In order for the patch to be applied during the building of the RPM, edit the  ./build-ps/percona-server.spec file and add the two lines that are highlighted:

Note that you have to number the patches, in this case I gave it the name patch1.

Creating New Source Tarball

If you use your own GitHub fork, or you made manual changes to the source (and you’re not using patch files), you should use that to create your own source tarball.

First, change the Percona Server version number. In this case, we are naming it  10custom to indicate this is not a standard build. You can adapt as you wish, just make sure the  VERSION file looks something like this:

Then make the source tarball:

Now you have the tarball in your source directory, but we won’t use it yet. We need to add some TokuDB submodules to it first. The make dist also kept the uncompressed directory, which we will use to create the tarball again when the TokuDB parts are included:

Preparing Build Environment

Environment Requirements

Make sure the build host has at least 10GB of free space and at least 4GB of RAM, or the build will fail at some point.

Install Dependencies

To build the RPM, we need to prepare our build environment and ensure the necessary build dependencies are installed:

Prepare RPM Build Tree

Next we need to prepare our build directory structure, in this case we will install it in ~/rpmbuild:

Download Boost Source

We also need to download the boost source (http://sourceforge.net/projects/boost/files/boost/1.59.0/boost_1_59_0.tar.gz) and put it in the  ~/rpmbuild/SOURCES/ directory:

Move Files to the RPM Build Tree

Copy the source tarball:

Also copy the  ./build-ps/rpm/* files:

If you have any patch files, move them to the ~/rpmbuild/SOURCES/ directory as well:

Then the percona-server.spec file goes into the ~/rpmbuild/SPECS directory:

Setting Correct Versions in the Spec File

Note the @@PERCONA_VERSION@@ contains our 10custom version number.

You can add your changelog information in the %changelog section.

Building RPM Packages

For Percona Server, making the RPMs is a two-step process. First, we need to make the SRPMS:

And then we can build the binary RPMs from the SRPMS:

Once the build is done, you can find the RPMs in the RPMS directory: