Pages

Showing posts with label packaging. Show all posts
Showing posts with label packaging. Show all posts

Friday, January 30, 2015

Rebuilding Fedora Packages for CentOS - A workflow

Why Rebuilding Packages

With the upgrade to CentOS 7, some of the services I was using are no more present in CentOS repositories. An example of this is BackupPC and ddclient, which I use for services and reachability of the machine.
I could install them through normal installation (tar.gz extraction,make config, make) but I feel this both as a waste and a danger. First of all, everybody using this will be doing the same, which is a wasted effort. Second,  I adopted CentOS for stability, which also means repeatability of configuration. Third, it's fun and satisfactory, run a yum install and having everything in place.

Fedora Compatibility

Upstream (aka "Red Hat Enterprise Linux 7") is mostly a combination of Fedora latest release (I guess from F18 onward), so in CentOS we find most of the novelties which have been developed in the last two to three years:
  • Systemd
  • Journal
  • FirewallD
  • Gnome 3
And a lot of other plumbing that I am forgetting about. Right now, repackaging an F21 spec for CentOS 7 is quite easy: these two distributions will slowly diverge in the next few years.

My Workflow

I adopted the following workflow: I assume that rpm development setup has been completed for the steps to succeed.

1 - Download source package

Downloading source packages is quite easy: install yum-utils on your fedora pc, and launch yumdownloader --source $packagename, eg:

yumdownloader --source ddclient

2 - Install src package

Copy the package on the CentOS machine, where a rpm dev environment is setup, and, as non-root account, install the src package. You will find the SPEC file in the ~/rpmbuild/SPECS directory, and source and patches in ~/rpmbuild/SOURCES.

3 - Adapt the SPEC file

You should edit the SPEC file, at least adding the CHANGELOG line in which you can write who you are, the date, and what you did. Experienced packagers can update the source files, apply further pathecs and so on. I suggest you check the following stuff:
  • the "Release:" line will contain a number, followed probably by %{?dist} macro, which will get substituted by the distribution abbreviation (el7 for centos, f21 for fedora). If not, correct it
  • Check the description and version, check with upstream if minor releases have been done, and if you wish to release a newer version of the package

4 - Rebuild the src package

Just type rpmbuild -bs $SPECFILE and you will have a new src package in ~/rpmbuild/SRPMS

5 - Mock build the package

Mock (yum install mock) will: 
  • create a chroot environment in /var/lib/mock/$target_architecture (in our case, epel-7-x86_64)
  • download build time packages 
  • build the package in the chroot environment
  • have a log of activities and the built packages in /var/lib/mock/$target_architecture/result
all of this simply entering: mock $src_package (eg - mock ~/rpmbuild/SRPMS/ddclient-3.8.2-2.el7.centos.src.rpm )

6 - Install the package

Time to test with a local installation of the package. Or you can deploy to your local repository for testing.

That's it. If you feel it, try to have a look at copr for distribution of your packages.

References:












Thursday, July 23, 2009

Building RPMs, part two - Pinax

Ok, so now we have the environment complete. First thing I want to package is Pinax. This is a nice little collection of Django applications which add some required stuff for most of web based applications.

On the link above you will find all the info for the project, so let's start. We will build the release version of Pinax (for development versions I have a side project, which I will show you at right time). Please note - all the release used are current for the day this entry has been written.

Download pinax version 0.5.1 from here and put it in rpmbuild/SOURCES. After that:
cd ~/rpmbuild/SPECS

rpmdev-newspec -t python pinax

Rpmdev-newspec creates the skeleton for a new spec file named pinax. The -t python option tells to create a skeleton with some python definitions in it (python definitions are laid out according to this wiki entry on the Fedora Project Wiki); you can see which skeletons are available looking in '\etc\rpmdevtools'.

Why Python? Well, my guess is that being DJango a Python framework, you know....

Let's look at the spec file and put some info into that. You can use any editor for the file (I use geany, fast and lightweight).

# sitelib for noarch packages, sitearch for others (remove the unneeded one)
%{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}
%{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")}

Name: pinax
Version:
Release: 1%{?dist}
Summary:

Group: Development/Languages
License:
URL:
Source0:
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildArch:
BuildRequires: python-devel

Wednesday, July 08, 2009

Building RPMS, part one

The following is an excerpt from the IRC Packaging Lesson ; in red instructions for root (please use sudo - never use a system as root):

  • yum groupinstall development-tools

  • yum install rpm-build rpmdevtools

  • rpmdev-setuptree

The last command will setup the following directories:

rpmbuild directory tree

BUILD


This directory will contain the build of the source code you want to package. Roughly equivalent to the directory where you tar xjf source.tarball.bz2 ; cd source.tarball ; .configure ; make

BUILDROOT


The directory where the package will be built.

RPMS


The rpm produced will end in this directory. This is the binary rpm, the one you want to install in the system to use that cute application of yours.

SOURCES


Tarballs will end up here. These are the .gz or bz2 downloaded to build the application; usually contains source files, in the common autotools format.

SPECS


Spec files are the files which define how to package software, which dependencies to look for, and some more stuff. It's the only file you need (apart from source code) to really build a package.

SRPMS


SRPMS files are RPMS which contain source and SPEC file to rebuild packages with rpm.

OK, right now I will close the entry. A new one in a few days.