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

[Niels de Vos]

On Sat, Jan 25, 2014 at 02:11:06AM -0800, Anand Avati wrote:
> On Sat, Jan 25, 2014 at 1:58 AM, 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.
> >
> > 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?
> >
> > Thanks
> > --
> >
> 
> 
> This needs to be sorted out. I'm not (yet) sure if we needed the X.Y.Z
> libtool versioning. Gfapi has been following the "do not change an
> interface once published" model, and only new APIs are added along with a
> bump in the corresponding pkg-version number. This is probably a
> safer/platform independent model than using libtool versioning.

I think that the big advantage of libtool versioning is the linker 
generated dependencies. With dependencies in the binaries, older 
versions of the libraries prevent the programs from starting. The 
automatic dependency generation in RPM even fails the installation if 
a version does not match.

My fear is that users will install a QEMU that has been build on a newer 
OS release, and hit runtime problems when libgfapi does not provide an 
expected function. From my understanding, this is easily possible when 
not using the libtool versioning.

For example, adding new functionality to libgfapi.so.6.0.0, but keeping 
backward compatibility, the 'age' needs to be increased, generating 
libgfapi.so.6.0.1. Existing programs linked against libgfapi.so.6.0.0 
will keep working. Newer programs requiring at least libgfapi.so.6.0.1 
will fail to get installed (thinking in terms of RPMs) on systems with 
libgfapi.so.6.0.0. The user will not get any runtime errors, the old 
version is still working and it is clear why updating to the new program 
failed.

When not using library versioning, the update of the program will 
succeed, and the next time the program is run and a new (missing) 
function is called, the program will likely exit. In case of QEMU, the 
users might see their VMs shutting down or not getting started, VM 
images that can not be created and so on. This would be way more 
horrible compared to the 'update failed' scenario.

It is well possible that I am missing something, and the above is wrong. 
In that case, I'm more than happy to be corrected.

Niels