> Does that mean glusterfsd is in glusterfs-server or glusterfs-fuse? It is > probably sufficient to leave glusterfs-fuse just have fuse.so and > mount.glusterfs.in > > +1
> 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 > glusterfs-geo-replication depends on 'glusterfs-fuse' too, as it works on aux-mount points. > 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. > > c) Kaleb mentioned about removing geo-replication objects from 'glusterfs' >> and having them in 'glusterfs-geo-replication' only. I think that might >> help unless we are breaking something in geo-replication by doing so. Do we >> remember the original intent behind packaging geo-replication objects in >> the 'glusterfs' package? >> > > Which are the geo-replication objects in 'glusterfs'? I don't recall any > incident where something from geo-replication package was moved into > glusterfs package for a specific reason. > > >> d) Remove mac-compat.so, rot-13.so, symlink-cache.so from 'glusterfs'. As >> practically nobody uses these translators today, I don't see much value in >> packaging them. >> > > +1 > >
_______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
