[redland-dev] Proposal to rearrange Redland packages

[Dave Beckett]

This is a summary of some thoughts I've been having about rearranging
the Redland packages after some poking by Edd.

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          - the C parts and docs, utilities
    (librdf, raptor, rasqal)
  redland-bindings - the API bindings
    (C#, java, perl, php, python, ruby, tcl, [Obj C])

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:

Source    Description Redhat package     Debian package
Package	 	      	     
	 	      	     
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
                      
(and for completeness)
	 	      	     
raptor	{  libraptor  raptor             libraptor1
	{    headers  raptor-devel       libraptor1-dev
        {  rapper                        raptor-utils
	 	      	     
rasqal	{  librasqal  rasqal             librasqal0
	{     headers rasqal-utils       librasqal0-dev
        {  roqet                         rasqal-utils


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

source    description redhat package     debian package
package	 	      	     

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 are: a more up-to-date redland/librdf since it'll be
easier for me to make new version and redland-bindings that can
revision at different, faster times as need be.  I'd propose that
redland-bindings would have a version number based on the redland
package version such as:
  redland 1.0
  redland-bindings 1.0-1.0

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).

Thoughts, comments?

Dave