[Gluster-devel] libgfapi version format change affecting QEMU-GlusterFS

[Bharata B Rao]

On Sat, Jan 25, 2014 at 3:28 PM, Harshavardhana
<harsha at harshavardhana.net>wrote:

> > QEMU uses pkg-config to get the version of libgfapi and accordingly
> enable
> > features. Currently, it checks for version 3 for base libgfapi support,
> > version 5 for discard API support and version 6 for zerofill API support.
> >
> > However with recent commit c2b09dc87, libgfapi version changed from 6 to
> > 0.0.6. So the question now is:
> >
> > Will there be any major/minor release of GlusterFS that will go out with
> > libgfapi version as 6 which QEMU should support or should QEMU just
> switch
> > over to using 0.0.6 ?
>
> 0.0.6 version from '6' - change was to address linking concerns and
> provide versioning
> support to not break linking objects in future while there are
> internal API changes.
>
> Sorry for the trouble it was an overlook on our part.
>
> Ideally it would have been great to check for GLFS_API_VERSION in 'glfs.h'
>  than
>  `pkg-config` so that all other third party linking objects could just
> probe this in their
> build rather than relying on `pkg-config` to make it more portable.
>

Initial versions of QEMU with GlusterFS support wasn't using pkg-config, I
switched over to pkg-config way subsequently based on the suggestions from
GlusterFS.


>
> AFAICS the patch only exists in 'master' branch its not present on
> release-3.5 or 3.4
> might not cause any trouble for QEMU in near future? or do you wish to
> have both
> version styles to make it backward compatible even on 'master' branch?
>

I am beginning to think that there are more issues with this change.

QEMU uses "pkg-config --atleast-version=3 glusterfs-api" to check the
minimum version of libgfapi that QEMU needs. Now from pkg-config
--atleast-version point of view, 3 is same as 3.x which is same as 3.x.x.

Now from 6 you went to 0.0.6, which will eventually reach 3.x.x at which
time the above mentioned pkg-config check starts becoming true which isn't
desirable. For QEMU this will look like a backward movement.

Also your commit message description says:

"In essence, every time you make a change to the library and
    release it, the C:R:A should change. A new library should start
    with 0:0:0. Each time you change the public interface
    (i.e., your installed header files), you should increment the
    CURRENT number."

So the version which was 3 became 5 when discard API was added and became 6
when zerofill was added. As per the above description, API addition will
result in a change to the installed header(glfs.h) and hence warrants a
change in CURRENT number ? Should you have changed the version to 6.0.0
instead of 0.0.6 ?

Regards,
Bharata.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140125/705557d8/attachment-0001.html>