Build system requirements

• we need to be able to layer our distribution on top of F7 (and, later on, F8) [cscott,bernie]

• easy way to resynch with upstream for the packages we need to fork [cscott, bernie]

• stable builds: we all agree we want builds done in a well specified, controlled environment so bugs are reproducible [bernie, cscott, marcopg, dcbw]

• ability to fork and unfork packages for the OLPC distribution [cscott, bernie]

• ability to add/remove custom packages from the build without going through a lengthy review process [bernie]

• ability for some of us to add/remove package ACLs for our developers without going through Fedora admins. [bernie, cscott]

• ability to create short-lived dist tags for experimental or integration streams such as "olpc-xtest", "olpc-sugar", "olpc-trial4", and so on [bernie]

• ability to create new long-lived dist tags for stable builds (say, every 3mo) [cscott]

• maybe some commitment that the Fedora build cluster will be somewhat more available and better performing than in the past. Very frequently our work-flow has been slowed down by builds of trivial packages that would take take more than one hour to complete. [bernie]

• there may be security concerns with building our binaries off-site. I'm sure RH already has strong security measures in place, but as you may know, OLPC has some very special needs. [jg, bernie]

• short-term, we need decent human-readable build changelogs (i.e. describing what was pushed into the build and why.) [mstone, cjb, cscott]

mstone's thoughts

Having established the viability of light-weight build-streams and having demonstrated that build-streams are attractive enough to warrant the attention of four OLPC developers, it would be nice to make the process more user-friendly in the same way that olpc-update was rehashed for general consumption after we demonstrated that it was a worthwhile thing to have around.

However, there are several interesting questions about how to proceed.

First, it seems now that there are two classes of people - those who want to maintain a build-stream and those who want a 'hacked up build' for short-term package-integration testing.

The former class of people need to deal with issues like build-reproducibility, bisection, changelogs, and build distribution. The latter just need a supremely lightweight build-branching mechanism and a convenient UI.

Some of the particular UI concerns that I have include:

• Producing a build system which does not require root privileges in order to function.
• Producing a build system which is packaged for installation on common distributions like Debian, Gentoo, and Fedora.

livecd-tools is a somewhat attractive option because it is under active development by an existing upstream community. However, it has already proved to be very frustrating for both cscott and wad. It is definitely not designed to support our exact needs at present.

pilgrim proper is frustrating to continue with because it fails to gracefully deallocate resources and because it is burdened by 20 or so accumulated 'hacks' required to produce OLPC images.