Why does so much virt stuff depend on glusterfs?

[Peter Robinson]

On Tue, Jul 23, 2013 at 12:57 PM, Kaleb KEITHLEY <kkeithle at redhat.com> 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)

Can't you split the translators into a glusterfs-common (or something)
that libgfapi depends on and then have glusterfs-fuse and other sub
packages. An in the case of translators why no split out all but the
defaults and any others the server admin should deal with.

Peter