Need to support gee-0.8

[Sam Hartman]

Apparently, gnome/glib upstream have decided to drop gee-1.0 in favor of the newer gee-0.8. Yep, that's right, the newer version has a lower version number. This is kind of unfortunate because we pass that into vala as an package for introspection, and we'll only have one version that we pass in.
Our API seems to work with either.
It's probably the case that our results of make dist will only work with one version of gee.

[Dan Breslau (dbreslau)]

This is in the "New" state in the internal Moonshot-UI project; but in the external "moonshot-ui (Debian)" project, it's in the Fix Released state. Is there any reason it should remain in the "New" state internally?

[Sam Hartman (hartmans)]

Yeah.
The patch we have is debian-specific and local.
You'll want to generate a patch that works both on centos6 and modern
debian, which will be fairly tricky
because

* vala runs at make dist time (before configure)

* You detect your gee version at configure time.

This looked really messy to me.

[Dan Breslau (dbreslau)]

I don't understand the two bullet items ("vala runs at make dist time (before configure)" and "You detect your gee version at configure time.") How do we compile the vala sources before we've generated the Makefile? Or do we compile to C without using a Makefile?

I've created a patch that selects gee-1.0 (the old library) or gee-0.8 (the new one), and likewise chooses between gtk+-2.0 and gtk+-3.0, based on what's installed on the host system. I'd guess that this is at least necessary, if not sufficient, for this task. I've tested it on Debian 7 (which has the older libraries), Debian 8 (which has the newer libraries), and CentOS 6 (which has the older libraries.)

I think we will also need to update the package repositories to reflect that moonshot-ui will use libgee-0.8 and libgtk+-3.0 in those distros where they're available, so that apt-get buildep moonshot-ui and yum build-dep moonshot-ui will use the newer libraries where appropriate. How do we do those updates?

[Dan Breslau (dbreslau)]

To try to clarify what I'm asking in the first paragraph above:

In the Moonshot UI source tree (as is standard with autotools), it's necessary to run ./configure in order to generate the Makefile. So the only way I can understand what you (Sam) wrote above is if you're referring to configure and/or make dist commands that are run in another directory -- call it a master directory -- but which ultimately build the Moonshot UI via a recursive make.

If that is what you meant, could you please give me some pointers about how that master directory is built, and how it builds the Moonshot UI?

If that's not what you meant, then in what sense is "make dist" run before "configure" ?

[Sam Hartman (hartmans)]

So, configure is run to make the makefiles.

however, vala is run to convert .vala files into .c files at make dist
time.
So, what happens is that

* you initially run configure and automake to get makefiles

* you run make dist; that runs vala and produces tar files.

Later someone unpacks those tar files and runs configure and make.
They don't run vala again; they use the .c files from the tarball.
They don't even need vala installed.

So, the set of vapis you link against is chosen by that original
configure time, *not* by the second configure.

Centos cares a lot more about make dist than Debian does to a certain
extent, although it's fairly bad form for the build process to overwrite
one .c file shipped in the upstream tarball with another generated at
build time, even on Debian.
On Centos, I'm somewhat concerned it may be worse than bad form and
actually cause problems.

--Sam

[Dan Breslau (dbreslau)]

I've marked this as "Fix Released" because we can now build a tarball for either gee-0.8 or gee-1.0, depending on what's in the local build environment. Will re-open if this fix turns out to be insufficient.

[Dan Breslau (dbreslau)]

Sorry, that should have said "Fix Committed".

[Adam Bishop (adam-omega)]

I took a look at the libgee packaged for CentOS 6.

It was last updated in 2010, and the package itself is flagged for potential removal from EPEL as it failed to build on CentOS 6.7.

I wonder if a better solution would be to build a libgee-08 ourselves, with an "obsoletes" against the libgee provided by epel.

If this is of interest, I can grab the SRPM from the latest fedora and see if it builds.

[Adam Bishop (adam-omega)]

The situation in CentOS 7 also looks a little fun, as they supply two versions:
  libgee06-0.6.8-3.el7.x86_64.rpm
  libgee-0.10.1-3.el7.x86_64.rpm

[Dan Breslau (dbreslau)]

I'm not sure if or how RPM package version numbers translate to library
version numbers. On my CentOS 6.7 VM, I get this:

    $ rpm -q libgee
    libgee-0.5.1-2.el6.x86_64
    $ pkg-config --list-all | grep gee
    gee-1.0 libgee - The GObject collection library

The second one is the one I trust :-)

According to Debian's documentation, including a third-party library
(such as our own version of libgee) is not an option. See
https://wiki.debian.org/UpstreamGuide#No_inclusion_of_third_party_code

[Sam Hartman (hartmans)]

For Debian we cannot include our own libgee.
But we could include our own libgee package in the Cento repo that we
use on Centos.
We'll have to do that if it is dropped from epel.