Difference between revisions of "Freeside:Documentation:RPMBuildSystem"

From Freeside
Jump to: navigation, search
(First draft of a guide to the RPM build system.)
 
 
(2 intermediate revisions by one other user not shown)
Line 9: Line 9:
 
===build-from-cvs===
 
===build-from-cvs===
  
This script compares the current contents of CVS with the contents last used to build a source RPM (SRPM) and if CVS has been updated, builds a new 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.
+
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.
 
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===
 
===Major releases===
Line 23: Line 25:
 
<pre>ovid --skip-perl-rpm-modules --packager='Yourname Here <youraddy@example.com>' Module</pre>
 
<pre>ovid --skip-perl-rpm-modules --packager='Yourname Here <youraddy@example.com>' Module</pre>
 
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.
 
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==
 
==Creating and Signing Binary RPMs==
Line 32: Line 36:
 
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.
 
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.
+
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:
  
Other command line switches allow building for only specific distributions, and also placing the results in a different yum repository than the default ("testing").
+
<pre>
 +
./build-freeside -a x86_64 -d sles -w 10 -v 1.7
 +
</pre>
  
 
Currently this script uses expect and rpm to sign the RPMs with the Freeside Internet Services RPM Signing Key.
 
Currently this script uses expect and rpm to sign the RPMs with the Freeside Internet Services RPM Signing Key.
Line 41: Line 49:
  
 
Binary RPMs are copied into a folder structure matching the layout of the yum repositories.
 
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==
 
==Updating the yum repositories==
Line 48: Line 58:
 
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.
 
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.
  
===update-repo===
+
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:
  
This is a one-line script that calls rsync to copy the updated repo structure to the live repositories.
+
<pre>
 +
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
 +
</pre>
  
 
=Future Directions=
 
=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.
 
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.

Latest revision as of 13:51, 26 July 2009

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.