Build system requirements

For information on current-day OLPC software build systems, see Build system.

The currency of this article or section may be limited by out-of-date information. There may be relevant discussion on its talk page

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

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

- we have that now by using the same methosds Fedora packages use.

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

- we need to get koji setup and running. then not accept packages that are not built in koji.

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

- we need to just request branches for packages. Tools are being worked on to make it easier - to unfork we need to untag the olpc builds

• 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]

- for anything that we have a OLPC branch for we can add people as needed

• 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]

- build logs, source, cvs is all kept publicly accessible. Access to the build servers is very limited.

• 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.

Dennis's thoughts

We currently have issues with reproducibility due to the random nature of the packages pulled in from dev.

we need to have some sort of a ui that will allow people to pull in packages and do one of images for testing. we should look at reviser/weviser using something that is hosted by us allows us to take developers distributions out of the equation.

I think that while we will have some hiccups with live-cd tools. long term i think its a much more flexible solution. If its too much we need to spend time developing pilgrim to be what we want it to be.

I think we need to package koji for debian. we should also push out mock configs and packages for debian so that people can do test olpc builds on debian systems.