Why does so much virt stuff depend on glusterfs?

[Richard W.M. Jones]

On Tue, Jul 23, 2013 at 05:27:20PM +0530, Kaleb KEITHLEY wrote:
> On 07/23/2013 05:20 PM, Richard W.M. Jones wrote:
> >On Tue, Jul 23, 2013 at 12:45:59PM +0100, Daniel P. Berrange wrote:
> >>On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote:
> >>>On 07/23/2013 03:44 PM, Richard W.M. Jones wrote:
> >>>>
> >>>>Not sure if glusterfs could be split into client and server parts
> >>>>and/or if that would help (only a "client" bit is needed).
> >>>
> >>>glusterfs already exists in client (glusterfs and/or glusterfs-api
> >>>and associated -devel rpms) and server (glusterfs-server) parts.
> >>
> >>Hmm, I wonder if there's another QEMU linkage problem here. QEMU
> >>seems to only use glfs_* functions in its code, but it is
> >>linking to "-lgfapi -lgfrpc -lgfxdr". It seems like it could
> >>probably link to just libgfapi.so, and thus only depend on
> >>glusterfs-api and not main glusterfs RPM.
> >
> >Ah yes, that's the key ...
> >
> >$ rpm -ql glusterfs-api
> >/usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so
> >/usr/lib64/libgfapi.so.0
> >/usr/lib64/libgfapi.so.0.0.0
> >
> 
> Even if libgfapi (from glusterfs-api) is used instead of client-side
> gluster fuse mount you still need the translators (from glusterfs)

OK I see that glusterfs-api depends on the other libraries which would
pull in glusterfs.

So it seems there is no way to fix this except to split up qemu's
block drivers, although there is a minor packaging problem that could
be fixed too.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW