qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] glusterfs-api.pc versioning breaks QEMU


From: Niels de Vos
Subject: Re: [Qemu-devel] glusterfs-api.pc versioning breaks QEMU
Date: Wed, 15 Apr 2015 11:07:32 +0530
User-agent: Mutt/1.5.23 (2014-03-12)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]