Wednesday 16 June 2010

buildj meets PackageKit

What could be more boring than hunting down dependencies one by one before being able to compile that shiny new source tarball or repository you just cloned?

Until now, I've focused on the benefits of the buildj GNOME build system for developers. But some of the latest features to land in my branch over last week will make going from source to a complete install easier than ever for users and testers by automatically determining and prompting to install required development and toolchain packages via the distribution's own packaging system, thanks to PackageKit.

The great thing is, buildj is smart enough to only acquire missing prerequisites from the distribution (or other dependency sources), henceforth fondly referred to as the cloud, if it can determine that doing so will satisfy the full set of mandatory build requirements:



Doing the Right Thing

The new feature is already pretty sane, and I'm working to ensure more correctness in behaviour:

  • If the dependency is already available from a manual installation or via jhbuild, it won't redundantly attempt to go and install the equivalent distribution package.
  • Likewise, if an available distribution package version is known to be too old or otherwise incompatible, there will be no attempt to install it.
  • Transactionality. If the build goes wrong and the user has no intention of fixing things, offer to remove the newly installed packages where it is safe to do so.

Relation to jhbuild

Astute readers will notice that jhbuild provides some similar functionality to that described. In fact, the new metadata for the build specification is developing with continued inspiration from both the dependency descriptions in jhbuild's modulesets and the distribution specifications from PackageKit's Catalog format.

All this means that in the short term the new metadata should be rich enough to act as a decentralised source of inter-project dependency information that can itself be used to populate jhbuild automatically.

And perhaps with wider adoption of buildj we'll eventually even be able to migrate that data out of the central jhbuild module completely and into the individual project repositories, both within and outside of git.gnome.org, extending the GNOME ecosystem and bringing in a new wave of developers - one of the most exciting stated goals of this Summer of Code project!

5 comments:

  1. Imagine a time when buildj is using buildj to build and find its own dependencies. Terrifying.

    ReplyDelete
  2. Wow, this looks really great!

    Keep the good work!

    ReplyDelete
  3. I've been really excited about this project since it was announced, and I'm looking forward to hearing about your progress throughout GSoC!

    ReplyDelete
  4. I love the buildj project !!!!

    Keep on rocking Emel

    ReplyDelete
  5. vay arkadas, hatuna gel nelerle ugrasiyor.

    ReplyDelete