Bug 619137

Building the bindings seems to require vala 0.9.4

Ugh depends rather than blocks

Created attachment 436124 [details]
spec patch

I updated vala to 0.9.4 in rawhide and F-14. It didn't compile against F-15 with vala 0.9.4 with my testing. Also I think the vala bindings would be better in its own sub package.

The way I understand it the bindings are purely a development-time addon, i.e not required at runtime for the actual executables that are produced using vala? As such I think its not much use splitting the development options further. 

I also tested the build with vala 0.9.4 and the attached patch on top of rawhide and it went ok.

(In reply to comment #5)
> The way I understand it the bindings are purely a development-time addon, i.e
> not required at runtime for the actual executables that are produced using
> vala? As such I think its not much use splitting the development options
> further. 

Bindings are normally in separate sub packages as they pull in separate deps. See python/ruby and other such examples.

(In reply to comment #6)
> (In reply to comment #5)
> > The way I understand it the bindings are purely a development-time addon, i.e
> > not required at runtime for the actual executables that are produced using
> > vala? As such I think its not much use splitting the development options
> > further. 
> 
> Bindings are normally in separate sub packages as they pull in separate deps.
> See python/ruby and other such examples.    

For bindings that are used at runtime of and end-user package sure. For bindings that are to be used only during development its just pointless. telepathy-glib-devel depending on vala is a non-issue imho.
If the vala bindings have some other use other than development then I'll concede they need a separate subpackage.

(In reply to comment #7)
> For bindings that are used at runtime of and end-user package sure. For
> bindings that are to be used only during development its just pointless.
> telepathy-glib-devel depending on vala is a non-issue imho.
> If the vala bindings have some other use other than development then I'll
> concede they need a separate subpackage.    

I believe your correct on this, though I haven't had a chance to look at this very close since I've been on the road the last week. Hopefully, I'll have some time on Wednesday to get to this.

Hmm, started building the vala bindings for tp-glib todayu, but they seem to be checking  for vala with pkg-config which is a no-no according to upstream (1). I'm on the road the next few days, but once I get a reliable internet connection I'll see if I can talk to tp-glib upstream about fixing this.

(1) http://mail.gnome.org/archives/desktop-devel-list/2010-August/msg00064.html

Comment on attachment 436124 [details]
spec patch

Latest tp-glib version is 0.11.12, and the patch is missing a BR on vala-tools

Created attachment 438359 [details]
New attempt to deal with the vala api versioning changes

Comment on attachment 438359 [details]
New attempt to deal with the vala api versioning changes

Ok, I am officially vala-confused. If the generated vala bindings are dependent on the internal vala api (now 0.10) then this needs more work and consideration.

Ok, I've made the changes to the devel branch in git so that the vala bindings are enabled but haven't built it yet since I would like some other eyes to give it a look over.

For now, I've put the vala bindings in a sub-package, but I'm not really convinced they should be. Glancing at how others are packaging them there is no consistent handling, so I'd like some other folks opinions. Here's my spec changes, and comments are welcomed:

http://pkgs.fedoraproject.org/gitweb/?p=telepathy-glib.git;a=blobdiff;f=telepathy-glib.spec;h=3c0dad03783a4e48f5a071931a04d7a1fb75220b;hp=d9f7118d7e735ff67a8619b937f33c662e4528b1;hb=211240a30738daff5e009e09c1d9cac9ec113d84;hpb=596c6b675144ec7f6db3c5f93570359bb7b749fd

(In reply to comment #13)
> Ok, I've made the changes to the devel branch in git so that the vala bindings
> are enabled but haven't built it yet since I would like some other eyes to give
> it a look over.
> 
> For now, I've put the vala bindings in a sub-package, but I'm not really
> convinced they should be. Glancing at how others are packaging them there is no
> consistent handling, so I'd like some other folks opinions. Here's my spec
> changes, and comments are welcomed:

That looks fine to me for the moment. Vala is now getting enough traction that there should probably be some packaging guidelines for them. I'll look at what is needed to make that happen.

From what I understand the vala bindings for tp-glib (and probably all other gobject libs) are a stopgap measure until vala itself fully groks the already generated gir introspection data.

telepathy-glib-0.11.13-1.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/telepathy-glib-0.11.13-1.fc14

telepathy-glib-0.11.13-1.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update telepathy-glib'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/telepathy-glib-0.11.13-1.fc14

telepathy-glib-0.11.13-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.