On Tue, Jul 23, 2013 at 12:57 PM, Kaleb KEITHLEY <kkeithle@xxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
