Bug 29070

Summary: delete telepathy-vala.pc when latest libfolks release no longer needs it
Product: Telepathy Reporter: Simon McVittie <smcv>
Component: tp-glibAssignee: Travis Reitter <travis.reitter>
Status: RESOLVED FIXED QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: normal    
Priority: medium CC: bugzilla
Version: git masterKeywords: patch
Hardware: Other   
OS: All   
URL: http://git.collabora.co.uk/?p=user/cassidy/telepathy-glib;a=shortlog;h=refs/heads/vala
Whiteboard: review+
i915 platform: i915 features:

Description Simon McVittie 2010-07-15 03:20:36 UTC
10:59 < smcv> treitter_, pwithnall: why does tp-glib install its .vapi/.deps in 
              $prefix/share/telepathy/vapi/telepathy-glib.vapi?
10:59 < smcv> treitter_, pwithnall: every other .vapi in Debian seems to be in 
              /usr/share/vala/vapi
10:59 < pwithnall> smcv: I don't know; the usual place is 
                   $prefix/share/vala/vapi
11:00 < pwithnall> I was guessing it's because they're not particularly stable
11:02 < smcv> wouldn't it be better to use telepathy-glib-experimental.vapi or 
              something, and knock off the -experimental suffix when it's 
              considered stable?
11:03 < pwithnall> smcv: Or telepathy-glib-0.0.vapi, yes, probably
11:03 < pwithnall> Have to see what treitter_ says
11:03 < smcv> well the problem with that is if you have more than 11 
              experimental versions, the .vapi version gets larger than the 
              real version :-)
11:04 < smcv> you can't parallel-install two versions anyway though, because 
              each tp-glib version corresponds to exactly one vapi version, and 
              different telepathy-glib versions aren't parallel-installable
11:05 < smcv> so there's not much point in versioning the .vapi until tp-glib 
              breaks ABI

Offering a .pc file to put the vapi directory onto the path seems to be highly unconventional (I haven't seen any evidence of it in Debian), so if there's a compelling reason to do this, it should be documented somewhere.
Comment 1 Travis Reitter 2010-07-15 18:37:34 UTC
(In reply to comment #0)
> 10:59 < smcv> treitter_, pwithnall: why does tp-glib install its .vapi/.deps in 
>               $prefix/share/telepathy/vapi/telepathy-glib.vapi?
> 10:59 < smcv> treitter_, pwithnall: every other .vapi in Debian seems to be in 
>               /usr/share/vala/vapi
> 10:59 < pwithnall> smcv: I don't know; the usual place is 
>                    $prefix/share/vala/vapi
> 11:00 < pwithnall> I was guessing it's because they're not particularly stable
> 11:02 < smcv> wouldn't it be better to use telepathy-glib-experimental.vapi or 
>               something, and knock off the -experimental suffix when it's 
>               considered stable?
> 11:03 < pwithnall> smcv: Or telepathy-glib-0.0.vapi, yes, probably
> 11:03 < pwithnall> Have to see what treitter_ says
> 11:03 < smcv> well the problem with that is if you have more than 11 
>               experimental versions, the .vapi version gets larger than the 
>               real version :-)
> 11:04 < smcv> you can't parallel-install two versions anyway though, because 
>               each tp-glib version corresponds to exactly one vapi version, and 
>               different telepathy-glib versions aren't parallel-installable
> 11:05 < smcv> so there's not much point in versioning the .vapi until tp-glib 
>               breaks ABI

Vala strictly ties the pkgconfig name to its "package name" elsewhere. So including one Vala package while building another requires "--pkg foo", which looks for foo.pc (to get the proper compiler and linker flags to use after generating the C code) and looks for foo.vapi to satisfy mappings between Vala and C symbols.

So I don't think we have much leeway in renaming telepathy-glib.vapi.

> Offering a .pc file to put the vapi directory onto the path seems to be highly
> unconventional (I haven't seen any evidence of it in Debian), so if there's a
> compelling reason to do this, it should be documented somewhere.

I thought it would be handy to confirm at configure-time whether the telepathy-glib Vala bindings are installed. But it looks like we can just check for the file in $(pkg-config --variable=vapidir vala-1.0). So we can just cut the telepathy-glib.pc file.

I've done that in this new branch. Please review and if you approve. I bump the nano version so libfolks can depend upon this version.

(The corresponding libfolks branch is http://git.collabora.co.uk/?p=user/treitter/folks.git;a=shortlog;h=refs/heads/tp-glib-vala-packaging - we'll need to merge this as soon as the tp-glib fix is in place. We'd need a lot of short-lived build cruft to be fully backwards-compatible here.)
Comment 2 Simon McVittie 2010-07-16 03:06:38 UTC
(In reply to comment #1)
> > Offering a .pc file to put the vapi directory onto the path seems to be highly
> > unconventional (I haven't seen any evidence of it in Debian), so if there's a
> > compelling reason to do this, it should be documented somewhere.
> 
> I thought it would be handy to confirm at configure-time whether the
> telepathy-glib Vala bindings are installed. But it looks like we can just check
> for the file in $(pkg-config --variable=vapidir vala-1.0). So we can just cut
> the telepathy-glib.pc file.
> 
> I've done that in this new branch. Please review and if you approve. I bump the
> nano version so libfolks can depend upon this version.

> -m4_define([tp_glib_nano_version], [1])
> +m4_define([tp_glib_nano_version], [2])

I'd prefer not to have libfolks depend on an unreleased telepathy-glib. We can do that without adding extra cruft, by doing the telepathy-glib change in two stages:

* change telepathy-glib to install in the normal vapidir, but still install telepathy-vala.pc, with the following change:

-vapidir=@datadir@/telepathy/vapi
-valaflags=--vapidir=${vapidir}
+vapidir=@datadir@/vala/vapi
+valaflags=

* (time passes)

* release telepathy-glib 0.11.11 with that change, which does not break the existing libfolks

* in libfolks git, bump the dependency to 0.11.11 and make it ignore telepathy-vala.pc

* (time passes)

* release libfolks 0.1.n with that change

* delete telepathy-vala.pc
Comment 3 Travis Reitter 2010-07-16 15:09:18 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > > Offering a .pc file to put the vapi directory onto the path seems to be highly
> > > unconventional (I haven't seen any evidence of it in Debian), so if there's a
> > > compelling reason to do this, it should be documented somewhere.
> > 
> > I thought it would be handy to confirm at configure-time whether the
> > telepathy-glib Vala bindings are installed. But it looks like we can just check
> > for the file in $(pkg-config --variable=vapidir vala-1.0). So we can just cut
> > the telepathy-glib.pc file.
> > 
> > I've done that in this new branch. Please review and if you approve. I bump the
> > nano version so libfolks can depend upon this version.
> 
> > -m4_define([tp_glib_nano_version], [1])
> > +m4_define([tp_glib_nano_version], [2])
> 
> I'd prefer not to have libfolks depend on an unreleased telepathy-glib. We can
> do that without adding extra cruft, by doing the telepathy-glib change in two
> stages:
> 
> * change telepathy-glib to install in the normal vapidir, but still install
> telepathy-vala.pc, with the following change:
> 
> -vapidir=@datadir@/telepathy/vapi
> -valaflags=--vapidir=${vapidir}
> +vapidir=@datadir@/vala/vapi
> +valaflags=

Good idea - I've done this in the new branch vala-packaging1. I'll finish up the rest of the procedure in a new branch after 0.11.11 is released.
Comment 4 Simon McVittie 2010-07-19 02:59:43 UTC
Looks good; please merge, but then leave this bug open, retitled to "delete telepathy-vala.pc when a libfolks release stops using it".
Comment 5 Simon McVittie 2010-07-26 04:31:04 UTC
(In reply to comment #4)
> Looks good; please merge, but then leave this bug open, retitled to "delete
> telepathy-vala.pc when a libfolks release stops using it".

I timed out and merged this, since I'd like to do a tp-glib release today.
Comment 6 Simon McVittie 2010-08-03 04:30:57 UTC
Blocked by GNOME bug 625928.
Comment 7 Travis Reitter 2010-08-10 15:46:05 UTC
(In reply to comment #6)
> Blocked by GNOME bug 625928.

No longer blocked, as that's now fixed. Please delete telepathy-vala.pc in master.
Comment 9 Simon McVittie 2010-08-17 03:02:59 UTC
Ship it.
Comment 10 Guillaume Desmottes 2010-08-17 03:03:46 UTC
Merged, will be in 0.11.13

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.