Distributing and deploying your software in an Linux environment should be done through the packaging system of the distribution(s) in use. That way your users can use a uniform way of installing, updating and removing all the software on their machine. But where and how do you start?
Some of our clients use the RPM-based openSUSE distribution, so I want to cover our approach to packaging and providing RPMs.
A RPM-package is built from
- an archive containing the buildable, vanilla sources
- a SPEC-file describing the packaged software, the steps required to build the software and a changelog
- optional patches needed to build and package the software for the target platform
The heart of the build process is the SPEC-file which is used by rpmbuild
to actually build and package the software. In addition to the meta data and dependencies it structures the process into several steps:
preparing
the source by unpacking and patchingbuilding
the project, e.g usingconfigure
andmake
installing
the software into a defined directorypackaging
the installed files into the RPMcleanup
after packaging
After creation of the SPEC-file (see my template.spec) the package can be built with the rpmbuild
-tool. If everything goes right you will have your binary RPM-package after issuing the rpmbuild -bb SPECS/my-specfile.spec
command. This rpm-package can already be used for distribution and installation on systems with the same distribution release as the build system. Extra care may be needed to make the package (or even the SPEC-file) work on different releases or distributions.
You will need a RPM-repository to distribute the packages so that standard system tools like yast2
or zypper
can use and manage them, including updates and dependency resolution. There are three types of RPM-repositories:
- plain cache sources
- repomd/rpm md/YUM sources
- YaST sources
As option 2 “YUM sources” gives you the most bang for the buck we will briefly explain how to set up such a repository. Effectively, it only consists of the same specific directory structure like /usr/src/packages/RPMS
on a webserver (like apache) and an index file. To create and update the repository, we simply perform the following steps:
- create the repository root directory on the webserver, e.g.
mkdir -p /srv/www/htdocs/our_repo/RPMS
- copy our RPMS folder to the webserver using
rsync
orscp
:scp -r /usr/src/packages/RPMS/* root@webserver:/srv/www/htdocs/our_repo/RPMS/
- create the repository index file using the
createrepo
-tool:ssh root@webserver "createrepo /srv/www/htdocs/our_repo/RPMS"
Now you can add the repository to your system using the URL http://webserver/our_repo/RPMS
and use the familiar tools for installing and managing the software on your system.
In the next part I want to give additional advice and cover some pitfalls I encountered setting the whole thing up and packaging different software packages using different build systems.
In part 3 we will set up a jenkins build farm for building packages for different openSUSE releases on build slaves.
3 thoughts on “Softwaredistribution using own RPM-packages and repositories, part 1”