Rearranging Redland packages
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 Package |
Description | Redhat binary package |
Debian binary 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 Package |
Description | Redhat binary package |
Debian binary 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).