On Thu, Apr 09, 2015 at 06:12:38PM +0200, Andreas Färber wrote:
Hello,
Hi!
Sorry for the late response, I'm travelling and have a rather full
agenda.
Testing QEMU v2.3.0-rc2, I have run into QEMU's glusterfs support being
broken on openSUSE Tumbleweed, resulting in its configure complaining:
[ 76s] ERROR: User requested feature GlusterFS backend support
[ 76s]configure was not able to find it.
[ 76s]Install glusterfs-api devel = 3
What our configure is doing is
pkg-config --atleast-version=3 glusterfs-api
on success followed by
pkg-config --atleast-version=5 glusterfs-api
and
pkg-config --atleast-version=6 glusterfs-api
Here's a short overview of the glusterfs-api.pc versions:
release-3.4: Version: 4
v3.5.0..v3.5.3: Version: 6
v3.5.4beta1 and release-3.5: Version: 4.${PACKAGE_VERSION}
v3.6.0: Version: 7.0.0
v3.6.1: Version: 0.0.0
v3.6.2..v3.6.3beta2 and release-3.6: Version: 4.${PACKAGE_VERSION}
So, both 3.5 and 3.6 series have gone backwards in their version
compared to released versions and are thus not backwards-compatible,
unlike what the commit message claims.
Oh, wow, that is a major mistake we made. I suspect that the original
solution was proposed for 3.4 and we incorrectly forwarde ported it :-/
Our tests were done with Samba, and they did not hit this problem.
Obviously they do not use any newer functions (yet). I was not aware
that QEMU did update their support for Gluster with newer releases.
openSUSE 13.1 and 13.2 and reportedly Fedora 21 are still at versions
with Version: 6, so not yet affected. openSUSE Tumbleweed is still at
v3.6.1 (with 3 0.0.0), but even once I get it updated to v3.6.2 the
checks for versions 5 and 6 would still fail, disabling features.
Naively I would consider versions jumping backwards a bug in glusterfs,
so I wonder why you chose 4.* and not 6.* and 7.* respectively.
This definitely is a bug on our side, I've just filed them in our
Bugzilla and will send patches later today. You can follow progress
here:
https://bugzilla.redhat.com/showdependencytree.cgi?id=1211836
How do you expect this to be handled by packages such as QEMU?
glusterfs-3.5.x should have glusterfs-api version 5.3.5.x
glusterfs-3.6.x should have glusterfs-api version 6.3.6.x
glusterfs-3.7.x should have glusterfs-api version 7.3.7.x
glusterfs/master should have glusterfs-api version 7.x.y.z
libgfapi provides versioned symbols, the .so will always stay at version
0 so that applications using libgfapi do not need a recompile when we
add more functionlity.
I'm sorry for the breakage, and hope to have it rectified in the next
updates that come out for the different versions. For now, you should be
able to either patch the QEMU dependency, or your glusterfs-api.pc
according to the above scheme.
Let me know if you spot any issues with this approach, I'm open for
suggestions.
Thanks,
Niels
