Fedora/RPM packaging

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

  1. 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).
  2. 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.
  3. 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.

6 Responses to “Fedora/RPM packaging”

  1. Mart Raudsepp Says:

    Regarding the GNOME python bindings (gnome-python, gnome-python-desktop and gnome-python-extras tarballs), one can just split it out into multiple packages. I figured binary distributions are doing it long ago, as it’s easier for them, but I guess not then…
    For Gentoo ford_prefect will be committing the split up packages to portage soon as his first bigger thing as an official Gentoo developer :) So we will have packages for every binding separately, so you won’t need to pull in the whole stack through libgnome bindings just because you just want to “import gconf”. The old package will be converted to a meta package that pulls in all the separate ones, so that the files installed by the monolith will be the same as when installed by the meta package, for easier migration by packages – they can gradually stop rdepending on the big thing at their leisure, considering their time and concerning keyword visibility matching.

    As for runtime dependencies, there are at least scripts around for Gentoo as well that can list you what packages are needed at runtime as figured out by it (of course doesn’t find dlopened stuff, probably just like Fedora, etc), so it’s easier to get a starting point to put in the ebuild. That said, in the GNOME world (and I imagine in most places), we just go with what configure.in checks and they are often listed all at once in variables in the same place and later those variables are used as necessary (sometimes inside various conditionals, like if a feature was enabled or not) , so that it’s easy to see minimal version dependency changes for example.
    For instance in gtkhtml’s configure.in (just happened to be unpacked here):

    # Required Package Versions
    m4_define([gtk_minimum_version], [2.10.0])
    m4_define([gail_minimum_version], [1.1.0])
    m4_define([gnome_icon_theme_minimum_version], [1.2.0])
    m4_define([libbonoboui_minimum_version], [2.2.4])
    m4_define([libglade_minimum_version], [2.0.0])
    m4_define([libgnomeui_minimum_version], [2.0.0])

    That said, these scripts and such tools should get collected better and perhaps integrated into a smaller number of tools

  2. Daniel Drake Says:

    Yes, gnome-python2 is already split up into subpackages in Fedora, but not well enough at the moment. https://bugzilla.redhat.com/show_bug.cgi?id=456122

  3. Rahul Sundaram Says:

    Newer versions of RPM can detect more build requirements at runtime but it is still provided explicitly for compatibility reasons at times. Yes, build customization can be a problem but the solution atleast in this case is to work with Fedora to split up packages more granularly. In fedora-devel list, some of the OLPC folks pointed a few issues related to this which are being resolved in the development branch of Fedora (Rawhide).

    “. 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 am not sure where you get this impression. Every single package is build using Koji (http://koji.fedoraproject.org) which itself uses mock directly against the spec files. You do not need rpmbuild at all. Maybe OLPC is doing something different that I am not aware of. Feel free to login to #fedora-devel and ask if you have doubts. Good to hear a different perspective nevertheless.

  4. Bernie Innocenti Says:

    Re “2. No build customisation”, one could use conditionals such as “%if 0%{?olpc}”, which expands to “01″ when olpc is defined to 1, and to 0 when it’s undefined. See the xorg-x11-server.spec in OLPC-2 for an example.

    Re “3. Convolution/confusion of build tools”, koji can build srpms: just say “koji build –scratch mypackage.src.rpm”. The problem is that it doesn’t let you build multiple packages dependent on each other, so it cannot be used to work on, say, a new version of X11.

    My main annoyance with RPM is that in case of errors you usually need to rebuild from scratch. There’s no easy way to “continue” a build after fixing the problem.

    And, of course, yum is a steaming pile of shit ;-)

  5. Rahul Sundaram Says:

    “My main annoyance with RPM is that in case of errors you usually need to rebuild from scratch. There’s no easy way to “continue” a build after fixing the problem.”

    rpmbuild has a –short-circuit switch.

    “And, of course, yum is a steaming pile of shit ;-)”

    Of course, it isn’t ;-) or atleast your comment wasn’t specific enough.

  6. Adam Says:

    This reminds me, I’ve got to install an OS with a smaller footprint on my old laptop. The thing takes about 234,734,698 hours to boot WinXP. I’ve used Fedora before and was quite happy with it. Have any other suggestions?

Leave a Reply

You must be logged in to post a comment.