Why does so much virt stuff depend on glusterfs?

[Daniel P. Berrange]

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)

Hmm, so normally the point of putting libraries in a sub-RPM is that
you can install it without pulling in the main toolchain, to save
space. Since the glusterfs-api RPM depends on glusterfs, you obviously
can't do that.

So I'm curious as to what the purpose of having glusterfs-api as a
sub-RPM is ?  Removing it saves 80 KB of disk space, so I guess it
isn't space related.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|