Freeside:Documentation:RPMBuildSystem

Introduction

The Freeside RPM Build System is used by Freeside Internet Services, Inc., to build binary RPMs of Freeside and its required Perl modules and update the public yum repositories from which RPM users can download and install Freeside.

The current build system is a collection of scripts to automate building the binary RPMs and updating the repositories.

Creating Source RPMs

build-from-cvs

This script compares the current contents of CVS with two CVS working directories (one for the 1.7 and one for the 1.9 branch of Freeside), and if CVS has been updated (i.e. running a CVS update changes the contents of the working directory), builds a new source RPM (SRPM). Since the script is intended for building Freeside when a full release has not been made and the .spec file has not been updated, it replaces the version and release in the .spec file with the Freeside branch number (currently 1.7 or 1.9) and the current timestamp (YYYYmmDDHHMMSS) respectively.

SRPMs produced by this script are placed in a holding area.

You should run this script after committing a significant change to CVS. You can also force an SRPM to be built by deleting a boilerplate file such as AGPL from the working directory.

Major releases

SRPMs for major releases can be built from the release tarball using rpmbuild:

rpmbuild -ts freeside-tarball.tar.gz

Required Perl Modules

This area of the build system could be more automated than at present. Currently, when a developer believes that a required Perl module is missing from the repositories, he/she must build an SRPM using Ovid:

ovid --skip-perl-rpm-modules --packager='Yourname Here <youraddy@example.com>' Module

where Module is the Perl module name. Ovid will build RPMs of the module and any modules it is itself dependent on. You will want to add --ignore=Module switches for common modules such as libwww that are part of the distribution yum repository and do not need to be regenerated.

(We're currently working on some scripts to automate building all the required Perl modules. These include genbundles, genmasondeps, and ovid2flute.)

Creating and Signing Binary RPMs

build-freeside

This script builds binary RPMs for all the distributions and architectures supported by the Freeside public yum repositories.

When called with no arguments, it checks the staging area used by "build-from-cvs" and copies any new SRPMs into its own working area, then builds binary RPMs from those SRPMs.

The script may also be called with a "-s" switch to specify which SRPM to use when building binary RPMs. (You can also "touch" an existing SRPM in the staging area to force it to be used.)

Other command line switches allow building for only specific distributions, and also placing the results in a different yum repository than the default ("testing"). For example, when building only the x86_64 binary RPMs for the Freeside 1.7 repositories for SuSE Enterprise Linux Server 10, you might use:

./build-freeside -a x86_64 -d sles -w 10 -v 1.7

Currently this script uses expect and rpm to sign the RPMs with the Freeside Internet Services RPM Signing Key.

The script invokes mock to build the binary RPMs for a given distribution and architecture.

Binary RPMs are copied into a folder structure matching the layout of the yum repositories.

This script currently builds for CentOS 4 by default.

Updating the yum repositories

refresh-repo

This script iterates through all the folders making up the various yum repositories and calls yum-arch, createrepo, or both, to update the repository's metadata after any of the files in the repository is changed. The script does not check for changes. It always updates the metadata when called.

The script now includes support for signed repodata on SuSE Linux.

By default, this script currently updates the CentOS 4 repository only.

Overview

Typical usage of these scripts:

cvs commit
ssh vserver
./build-from-cvs
exit
./build-freeside -d sles -w 10 -v 1.7 -a x86_64
./refresh-repo -d sles -w 10

Future Directions

Since our existing scripts duplicate what the Fedora/EPEL build system (koji) and the OpenSuse builder do, we're looking at replacing some or all of them with one of the maintained products when time allows.