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 :| -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
