Build system
Contents
Maintainers
1. Scott Ananian (c_scott)
2. Michael Stone (m_stone)
3. Chris Ball (cjb)
Build Branches
Frequently, we find ourselves needing to integrate complicated changes that cut across packages. To make this easier, we make it very easy to 'branch' a build in which the integration can be performed safely, without interfering with other work. If you are trying to perform a delicate piece of integration for which it would be helpful to have a separate build, please contact one of the build system maintainers.
We currently have four build branches: joyride, meshtest, xtest, and rainbow.
Instructions for Use
To add a completely new piece of software (either a new activity or a new package) to a build, two steps are necessary.
1. Modify streams.d/olpc-development.conf to mention the new activity or new package.
2. Include a source code package (.xo or .src.rpm) and a binary package (.xo or .rpm) in your dropbox (which is located at ~/public_rpms/<build>/ on dev.laptop.org). You will need to create the folder, here is an example for joyride:
mkdir -p ~/public_rpms/joyride
Note: do not remove the .xpm's or .xo's from the public_rpms location, not even after they already showed up in an image: public_rpms is not a temporary place where the build systems grab them; it will grab them from that location every run.
3. Update ~/public_rpms/<build>/ChangeLog to describe the changes made by the packages you are introducing.
ChangeLog Format
The format of this ChangeLog is
<pkg-lines> (containing ".xo", ".rpm")
<detail-lines> (not containing the string ".xo", ".rpm", "--")
-- <signature> (-- is the line marker)
<pkg>
<pkg>.rpm
<detail>
-- <signature>
An example:
Etoys-61.xo etoys-2.2.1710-1.noarch.rpm etoys-2.2.1710-1.src.rpm * changed activity launch to match new Sugar * words in tiles separated by spaces not camelCase * adds "distance to" and "bearing to" tiles * better .pot sort order -- Bert Freudenberg <bert@freudenbergs.de> Tue, 16 Oct 2007 squeak-vm-3.9-12olpc1.i386.rpm squeak-vm-3.9-12olpc1.src.rpm * big merge with trunk * unicode key events * fixed dbus plugin -- Bert Freudenberg <bert@freudenbergs.de> Mon, 15 Oct 2007
Output from the Build System
The build system produces things:
1. An RPM repository, currently located under the repository root
2. The output of the build system is currently located under the streams root
Implementation Details
The build system we want to have consists of the following components:
/------\
| F7 yum |--------+
| repos | |
\------/ V
/--------\ +--------+ +----------+ +---------+ /------\
| upstream | | distro | | pkg build| |compose | | stable |
| src |-->| SCM |-->| system |-->| tools |-->| rainbow|
| repos | | (CVS) | | (Koji) | |(joyride)| | xtest |
\--------/ +--------+ +----------+ +---------+ \------/
^ ^ ^
/--------\ | | |
|patches |-----+ | + - - - - - - - + |
\--------/ | | dropbox | |
+----->| system |----+
/--------\ | | (public_rpms) |
| olpc | | + - - - - - - - +
| sources |-------+
| (GIT) |
\--------/
|-----------| |----------------------------| |-----------------------|
sources package maintenance package composition
CVS,GIT Koji, Mock, rpmbuild mash, pilgrim, ChangeLogs
The one we actually have is fairly similar but the package-construction step is done partially in Koji and partially by individual package maintainers using tools like Mock and rpmbuild.
