Dave Beckett's blog

Rearranging Redland packages

2004-07-16 15:44

This is a summary of some thoughts I've been having about rearranging the Redland packages after some poking by Edd Dumbill based on an email to redland-dev.

The problem I've been having is that the (7 or 8) language APIs are changing at a faster rate than the core C redland librdf. This is a good thing of course, but it affects releases in two ways - I can't get the Redland release out while lots of the bindings parts are in flux, and fixes to the bindings are often quickly made in CVS but can't be shipped because the librdf or other bindings are being worked on.

So... I'm proposing to split out the redland package into two:

redland (librdf, raptor, rasqal)
the C parts and docs, utilities
redland-bindings (C#, java, perl, php, python, ruby, tcl, [Obj C])
the API bindings

In Debian GNU/Linux terms the above would be called source packages, which are used to generated installed things that are binary packages. I currently make the following Redhat/Debian packages according to each package convention (with Raptor and Rasqal included for completeness):


Source\ Description Redhat binary\ Debian binary Package package package(s)


redland librdf redland librdf0

headers redland-devel librdf0-dev

perl API redland-perl librdf-perl

python API redland-python python2.2-librdf python2.3-librdf

ruby API   librdf-ruby

raptor libraptor raptor libraptor1

headers raptor-devel libraptor1-dev

rapper   raptor-utils

rasqal librasqal rasqal librasqal0

headers rasqal-devel librasqal0-dev

roqet   rasqal-utils


So the proposal is to rip out the language bindings to make:


Source\ Description Redhat binary\ Debian binary Package package package(s)


redland librdf redland librdf0

headers redland-devel librdf0-dev

redland-bindings perl API redland-perl librdf-perl

python API redland-python python2.2-librdf python2.3-librdf

ruby API   librdf-ruby


(raptor and rasqal as before)

Package end users will see no difference, since the binary packages will be the same. Anyone building from source will now need one more package, so this affects those users and distributions that use source-based packaging such as the BSDs, Gentoo etc. Those will have to deal with the split by adding some build-time dependency.

The advantages I see are:

  • a more up-to-date redland/librdf since it'll be easier for me to make new versions
  • redland-bindings can revision at different, faster times as need be.

I'd suggest that redland-bindings would have a version number based on the redland package version such as:

redland 1.0.0 redland-bindings 1.0.0-2.5

It might be that new or improved bindings appear in a separate package again like redland-sharp, redland-ruby (there's a substantial change to this one not yet fully merged) and get merged into redland-bindings as they get stable.

Another thought is to remove raptor and rasqal from inside the redland package. This would have additional advantages for me trying to keep the three things consistent compared to their separate releases, but it would again mean more downloads for those building from source (although for example, raptor is in the BSD, Gentoos on it's own already).