Another model can be:
0. glusterfs-libs.rpm - libglusterfs.so libgfrpc.so
libgfxdr.so
1. glusterfs (depends on glusterfs-libs) - glusterfsd
binary,
glusterfs
symlink, all common xlators
2. glusterfs-rdma (depends on glusterfs) - rdma shared
library
3. glusterfs-geo-replication (depends on glusterfs) -
geo-rep
related
objects
4. glusterfs-fuse (depends on glusterfs) - fuse xlator,
mount.glusterfs
5. glusterfs-server (depends on glusterfs) - server side
xlators, config
files
6. glusterfs-api (depends on glusterfs-libs) -
libgfapi.so and
api.so
7. glusterfs-resource-agents (depends on glusterfs)
8. glusterfs-devel (depends on glusterfs-libs) - header
files for
libglusterfs
9. glusterfs-api-devel (depends on glusterfs-api) -
header files
for gfapi
This way qemu will only pick up libgfapi.so libglusterfs.so
libgfrpc.so
and libgfxdr.so (the bare minimum to "just execute")
for the
binary to
load at run time. Those who want to store vm images
natively on
gluster
must also do a 'yum install glusterfs' to make gfapi
'useful'.
This way
Fedora qemu users who do not plan to use gluster will
not get
any of the
xlator cruft.
I like the idea about users of qemu not having to do with
non-required glusterfs cruft but with this model we still have
glusterfsd binary being pulled in for consumers who want
libgfapi alone.
How? libgfapi depends only on glusterfs-libs. Whereas glusterfsd
is in
glusterfs rpm.
In the scenario when somebody tries to use the gluster client
xlators via libgfapi, we would end up installing glusterfsd still.
Do we really need that to happen?
Isn't the concern that someone who is not interested in using glusterfs
is now forced into removing qemu, libvirt and the whole virt shebang
when trying to uninstall glusterfs rpm? glusterfsd coming along when
common xlators (client xlators) are installed is probably not a big
deal.. That would happen only for users who are interested in glusterfs
anyways.