Another of GSoC ideas that I volunteered to mentor for our GSoC was adding support for BitBake to the openSUSE Build Service. In this post I want to talk about why do I think that BitBake support for openSUSE Build Service will be useful and why do I think that OpenEmbedded is actually pretty cool.
What is BitBake? Why is OpenEmbedded cool?
BitBake is a build system used mainly by OpenEmbedded. In a way it is kind of similar to what openSUSE does for us. It takes one sources and makes it possible to build them for many distributions. There are some differences though. Let’s start with few notes a out OpenEmbedded. BitBake description will make more sense once you’ll know what OpenEmbedded is. It’s a meta distribution. You can think about it as a common code base for multiple distributions. It has many packages. It also contains distribution settings. Same source can be built in different ways for various distributions. Each distribution can choose which version of which package does it want to have in which release. It can choose package management system, preferred providers for virtual packages and many other things. BitBake is then used to build whole distribution out from BitBake recipes. From recipes that all maintainers from all distributions work on together at one place. And yes, it doesn’t support spec or dsc files. You have to write .bb files. But it will build .rpm, .deb, .opk or .tgz out of it. All from one recipe. And that recipe is easier to write and more powerful then spec. If you never tried packaging for Debian, trust me that it is also much easier than Debian packaging. I actually had a presentation on openSUSE Conference 2009 about what can be done in BitBake and how it makes packagers life easier. Let’s quickly mention few features that BitBake has.
Everything from one recipe
This was already mention, but it is quite important so I want to mention it once more. It can create both .rpm and .deb from one recipe. So you don’t have to learn two different packaging method if you are upstream and want to provide binary packages for as many distributions as possible.
Class based packaging system
What is so great about inheritance in packaging? It helps you reduce copy & paste and makes it easier to do some policy changes. Let’s take a look at some example. Let’s say, that you are packaging some KDE game. How would you do that? In spec, you’ll probably need to figure out how to call cmake, how to pass right KDE paths to it, how to make games rights ok and such. Then you’ll white down the spec file. Or probably you’ll just grab some other KDE game and copy & paste its spec file with minor adjustments. What you’ll do in BitBake is something like
inherit cmake kde games
because BitBake has a class for compiling cmake programs, it has a class that knows how to package KDE programs and how to package games. And you are done. That’s all. You don’t need to write any %setup, %install or %files. It knows what it should do. You can start packaging something else 😉 If you know Gentoo ebuilds, BitBake recipes are a little bit similar, but focused on binary distributions.
New sub-packages on the way
One disadvantage that writing spec files has is that you have to know beforehand haw many and what sub-packages you will be creating. And you have to name all of them explicitly. BitBake on the other hand let you do some neat tricks. You can compile your whole package and decide about sub-packages after that. Why is it cool? Let’s imagine for example Pidgin. It contains many plugins and let’s imagine that you want to make package for every single plugin. In .spec file, you’ll have to write down all of them manually. In BitBake you can use something like this:
do_split_packages(d, purple, '^lib(.*)\.so$', output_pattern='libpurple-protocol-%s', description='Libpurple protocol plugin for %s', prepend=True, extra_depends='')
This will split packages automatically, less writing for you and it will work even if Pidgin developers will add another plugin or take one of them away.
Student
This time I don’t have any student in my pocket who wants to work on it. And it will be quite tough job. I think it would be definitely the most difficult idea I’m suggesting for GSoC. And I think it would require somebody who is willing to create many ugly hacks for greater good. The ends justifies the means 😉 It will require some serious digging into BitBake and obs so student will have to be quite independent as after a little digging I wouldn’t be able to help him much and he’ll learn more low level stuff than I want to know. But I think if this gets done, it will be great.