Since starting at One Laptop per Child I have been doing some distro work on the OS platform for the XO laptop. The platform is based on Fedora 7 and I have been working on rebasing us onto Fedora 9 for the next release.
Having very little distribution experience outside of developing Gentoo for the last few years, I’ve found some aspects of Fedora’s binary package (RPM) workflow particularly interesting:
- Automatically detected dependencies: In Gentoo ebuilds, we have to state that package A depends on library B. In Fedora, when building the binary package, the build tools determine many runtime dependencies automatically so there is no need for developers to manually list all dependencies in spec files.
- Chroot build environments: All packages are built in an otherwise-empty chroot. The build system creates a chroot, quickly installs all of the base binary packages and the build dependencies, then builds/installs a package, produces a package, and throws the chroot away. This allows for predictable build environments and is good for QA.
- Community access to the build box: All packages are built by Koji. Koji has a nice “scratch-build” system where you can throw a source RPM at it, and it will build it and serve it back to you on a webpage a few minutes later. Great for build testing and handy if you don’t have a complete build environment locally. The scratch-build service is open to non-developers assuming they have been through the click-through contributor agreement.
- Subpackages: It’s pretty neat how one spec file (equivalent to an ebuild in some ways – textual build scripts) can actually produce several packages. Your spec file takes one upstream tarball, unpacks/compiles/installs it, and then specifies which of the installed files belong to which subpackage.
Naturally, there are some drawbacks too:
- Build dependencies: Even though many runtime dependencies are automatically detected, you still need to specify the components required for compilation. Remember, each package is built in a clean chroot. You end up having to specify most of the dependencies anyway (although it is still convenient in that you do not have to specify which subpackage has which dependencies – that is determined automatically).
- No build customisation: OLPC have to fork a few packages which have wacky dependency chains, just to disable support for a certain feature or whatever. Forking away from upstream is undesirable but sometimes necessary. For example, we had to disable libgnome support in GNOME’s Python bindings to avoid libgnome being pulled into the build. libgnome was pulling in the following packages: audiofile bluecurve-icon-theme control-center-filesystem esound-libs fedora-gnome-theme fedora-icon-theme fedora-logos gail gnome-icon-theme gnome-keyring gnome-themes gtk-nodoka-engine libart_lgpl libbonoboui libgnomecanvas libgnomeui libutempter metacity nodoka-metacity-theme pyorbit. Ouch.
- Convolution/confusion of build tools: To build a package, you can use rpmbuild to do it on your live system, or you can use mock to do the clean chroot thing I described above. Or you can use koji’s command-line client to upload it to koji. Not everything can be done through koji/mock, e.g. you still need to use rpmbuild to build OLPC’s kernel. Also, rpmbuild is the only tool that can build a source RPM, I think.
I’ve also been impressed by the Fedora development community. The community recently made the realisation that OLPC is Fedora’s biggest deployment (over 400,000 XO laptops worldwide, 55,000 more built and distributed each month, 100% of them running Fedora). Greg Dekoenigsberg recently announced the Fedora OLPC special interest group which sounds promising.