RPM repository do it yourself

What are we talking about

Good day,% username%.

Today I would like to tell you how easy and unobtrusively to create your rpm-repository, as well as fill it with optimized packages for your favorite distribution. And so, for this we need: a favorite one distro (in my case it's a VZ card with Centos 5.5), rpm-build, mock, createrepo. All packages can be found in the standard centos repositories.

Build-root and company

For example, we will collect haproxy . Instructions on the Internet do not recommend to build packages under root, we will not resist them and create a user build. We go under the newly created user and in the home directory create a number of directories and files that we will need later:

mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros

A little bit of explanation. In SOURCES we will download the sources of those packages that we want to build, as well as all the patches and configs to these sources. The BUILD system will unzip your package, apply patches to it and compile the whole thing, in our case it will not be used further. RPMS - there will be layouts broken by architecture (noarch, x86_64, x86) collected packages are also not used. SRPMS - here rpmbuild will put a .srpm package with which we will continue to work. SPECS - here will be the most interesting part. The fact is that to build rpm from source, we need a .spec file that describes what we build, with what configure parameters, changelog our rpm and other things, I will try to describe it below.
')

SPEC and what it eats *

Immediately I warn you: to compile .spec files yourself is like death, therefore I usually look for them on the Internet or they are attached to the source code of the package. But the main points are still worth considering. For clarity, you can peep here .

In the "header" we have the name, version, license type, and a couple more lines. Basically, you may need to change the release number and possibly add patches (Path1, Path2). It was also sometimes necessary to shamanize with BuildRequires and Requires. The first is the dependencies for the assembly, the second is the dependencies of the package itself for the correct robots. Small hint - in Source0 there can be both the name of the package that you have in SOURCES, and the path to the file somewhere on the Internet.

Next comes an extended description of the package, preparation for assembly, perhaps the imposition of patches and directly assembly. In the% build section, you can specify parameters for gcc - CFLAGS, CPPFLAGS, and so on. For us, a particularly interesting section can be% configure, which unfortunately is not in the example. It is in this part that the settings for the specific package you are building are set. Other sections I will not describe what they perform can be understood by name. The only thing I want to notice is that in the% files section it will be necessary to enumerate what exactly from the build-root should be collected in your rpm. Sometimes it can be a very long list. It is possible to ignore some files, but unfortunately I have not figured it out yet.

We collect srpm

With this, everything is simple, after you have compiled / found an .spec file on the Internet / package and put it in SPECS, run rpmbuild:
rpmbuil -bs haproxy.spec

This will create in the SRPMS directory the appropriate rpm from which later we will make a package for your distro.

Use the mock, young padawan

Actually, what we need is a mock package - with its help we will collect the resulting .srpm and “screw” all the necessary dependencies to it for installation in your distribution. He knows how to build for all versions of fedora (i386, x86_64, ppc), redhat 8/9, centos from version 3.

In order to build a package under centos5 x86_64 we need to make the link default.cfg -> /etc/mock/centos-5-x86_64.cfg in the / etc / mock directory. This file contains a list of standard repositories for centos. You can easily add additional repositories there, then the mock will assume that packages from it are always in your distro and can be used to satisfy dependencies.

Defaults.cfg may also be useful. Mock creates a chroot in which there is a minimal system with everything needed to build - gcc, make, autoconf, and so on. I had to add specific packages not going to the original chroot, this is done in the config_opts ['chroot_setup_cmd'] line .

Build the package by setting mock on the .srpm file:
mock ~/rpmbuild/SRPMS/haproxy.srpm
If everything goes well, then in / var / lib / mock / centos-5-x86_64 / result / you will get rpm-ready packages for installation. If something goes wrong, then there you can see the log files. In root.log there will be a process of creating chroot, in build.log there will be an assembly.

Let's say everything went well and you got the cherished haproxy.rpm, haproxy-debug.rpm. It remains the simplest.

Repository

We are creating the RPMS directory somewhere, let's say this is / var / www / htdocs / and transfer the resulting files to it. Yes, this part is already being done from a more privileged user. The process of creating a repository is just as simple:
createrepo /var/www/htdocs
Inside we get our RPMS and repodata directory.

Now on the necessary servers we create a .repo file and use our repository. When adding packages, you must create createrepo each time, and on servers - yum clean all, so that fresh packages from your repository are visible for installation.

* To expand consciousness and achieve Zen when creating .spec files, I suggest referring to the following documents:
fedoraproject.org/wiki/How_to_create_an_RPM_package
www.rpm.org/max-rpm-snapshot
tldp.org/HOWTO/RPM-HOWTO

That's all that I wanted to tell you. I hope someone will be useful.