mock and buildsystems.

May 16, 2005

We’ve been using mach in fedora extras as a mechanism for making buildroots and building packages. The problem I kept running into is that mach was made to do a bunch of things and the more I looked at it the more I realized that we didn’t need a lot of those features. It’s always been my view that an unused feature is just a place in the code where bugs can occur. So I started, at first, just stripping out the uneeded features from mach. Then after doing that for a couple of hours I realized it would be easier to just take the useful functions and ideas from mach and put them into a new program that:

  1. thomas wouldn’t have to worry about merging back in
  2. wouldn’t get us caught up in some other release of things
  3. could be hacked to be integrated with the buildsystem automation code more readily

So I came up with mock. It has a significantly reduced feature set from mach and if I have my druthers it will stay that way. It’s named mock b/c it is a lesser or fake ‘mach’. I thought it was a clever name.šŸ™‚ Anyway mock only makes a chroot, installs a srpm given to it on the command line, rebuilds the srpm into another srpm inside the chroot, checks for its builddeps, installs those, then rebuilds the new srpm into binary rpms. It doesn’t try to do anything terribly clever.

It doesn’t handle more than one srpm at a time. If you try to use the same chroot as someone else at the same time, on the same machine it will probably explode, luckily, that isn’t a feature set requirement I needed to deal with. Moreover it makes it very trivial to make a new chroot under a new name but with the same repositories as an older one. I’ve got to work on the README for it and make it clear how/what it does.

So right now it’s the base I’m working from for package rebuilding and it’s probably where I’ll be going for the fedora extras buildsystem work.

Speaking of that Dan Williams has done some terribly cool work to make it the infrastructure for build automation much more interesting and robust. We’ll be making his new automation work interact with mock sometime this week and seeing about a deployment for building packages for fedora extras. After that I can think of a dozen systems that might be able to benefit. Dan has mentioned the aurora project. Colin mentioned the potential mpackage site and I’m sure there are other less obvious but still cool uses.

I’m really looking forward to it unfolding. In comparison to where fedora extras was back in november we’ve come a long way. Hope we can keep it up.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: