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

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

[Andreas Färber]

[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]

Hello,

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.

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.

How do you expect this to be handled by packages such as QEMU?

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Niels de Vos]

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