ReleaseEngineering/PuppetAgain/HowTo/Build RPMs
How to Build RPMs
Prepare the Package
For this example, I want to build a new mozilla-python27 package based on 2.7.3 instead of 2.7.2. I'm going to fetch the original .src.rpm and extract it into a subdirectory:
$ wget http://repos/repos/yum/releng/public/CentOS/6/x86_64/mozilla-python27-mercurial-2.1.1-4.el6.src.rpm $ mkdir mozilla-python27 && cd mozilla-python27 $ rpm2cpio ../mozilla-python27-mercurial-2.1.1-4.el6.src.rpm | cpio -ivd
Then edit these .spec file lines to update the Python version and package release number:
%define pyrel 3
Release: 0%{?dist}
Build a .src.rpm
There are two ways to build a source RPM described below.
Build a .src.rpm Using Mach
Mach automatically downloads required source tarballs and patches and can handle multi-package builds with inter-dependencies.
Install/Configure Mach
Start with a minimal install of CentOS 6.2.
$ yum install wget createrepo gcc make $ wget http://thomas.apestaart.org/download/mach/mach-1.0.2.tar.gz $ tar xzf ./mach-1.0.2.tar.gz $ cd mach-1.0.2 $ ./configure --disable-selinux $ make $ make install $ chmod u+s /usr/local/sbin/mach-helper $ groupadd mach $ useradd -g mach -m mach $ passwd mach
Due to a permissions bug I hit with mach (during a file copy), we'll continue as root.
Create /root/.machrc:
config['centos-6-x86_64-os']['macros']['dist'] = '.el6' config['centos-6-i386-os']['macros']['dist'] = '.el6'
Build the .src.rpm
$ mach build /path/to/spec
Build a .src.rpm Using Mock
Install/Configure Mock
- Install mock
- Copy the mock-config folder to your home directory (this example uses /home/cltbld/mock-config).
Find a suitable machine with 'mock' installed. It's best to do this on a target machine, since its /etc/mock/default.cfg will already be set up correctly.
Download the srpm from puppetagain.pub.build.mozilla.org/data/repos/yum/releng/public and unpack it:
$ mkdir foopkg && cd foopkg $ rpm2cpio $srpm | cpio -ivd
You should see a .spec file appear. Check that it is identical to the one in http://hg.mozilla.org/build/puppet under modules/packages/manifests/mozilla e.g., with an md5 hash. If not, figure out what the differences are, and which corresponds to the running version of the package.
Edit the spec file to your heart's content.
Build the .src.rpm
$ mock --buildsrpm --spec /path/to/spec --sources $PWD
The script output will tell you where the SRPM is. Copy it somewhere else, or mock will delete it.
Build the Package
Now we want to rebuild the package using our .src.rpm created above.
Build using Mach
Included here for reference, but it is preferable to use Mock to build the final binary package (see "Build Using Mock", below) as the steps have been tweaked to use only our internal Yum repos. This is desirable to get exactly the right binary package output.
$ rm -rf /usr/local/var/tmp/mach/* $ mach='mach --debug -r centos-6-x86_64-os' $ $mach clean $ $mach build mozilla-python27/python27.spec
Note: adjust the target to 'centos-6-i386-os' to generate a 32-bit package.
In this case, though, I wanted to use mock (not mach) to build the final package since my mach build machine does not have access to the Mozilla yum repos. We can use the .src.rpm generated above and feed that to mock.
Note that this is a simple example. mach has an advantage over mock in that it figures out dependencies when building multiple packages and automatically pulls in source files (normally a manual operation). This can save a lot of time and hassle.
Build Using Mock
- Fetch the .src.rpm you built earlier.
- Execute these steps to build:
$ mock='mock --configdir=/home/cltbld/mock-config -r epel-6-x86_64 -v' $ $mock --clean $ $mock --rebuild mozilla-python27-2.7.3-0.el6.src.rpm
- The script will tell you where the results are available.
- Use 'epel-6-i386' to build a 32-bit package.
Other Dependencies
If your package depends on other mozilla-specific packages, I'm not sure what the best way to build is. The less-than-awesome technique I used was to hack /etc/mock/epel-6-x86_64.cfg to include pointers to the public mirrors of the puppetagain repos.
Testing
For testing purposes, it's best to install the RPM locally, rather than dropping it into the puppetagain data directory and risking affecting production. You can do that too, if you're confident it won't affect anything.
Review
For review, include the modified .spec in your r? for changes to the puppet repository.
Remember, if the package can't be 100% re-created from data in the PuppetAgain Mercurial repository, you're doing it wrong!
Landing
See ReleaseEngineering/PuppetAgain/Packages for details on landing the change.