I disagree. Since the cli will not build a volume with it, it doesn't need to be in a package. Since its value is purely academic, only the source code matters, and it will still be in the git repo and the src tarball.
Jay Vyas <jayunit...@gmail.com> wrote: >minor point: rot-13 is a good one for learning and playing with >gluster. i would suggest keeping it in the releases.! > > >On Jul 29, 2013, at 7:21 AM, "Kaleb S. KEITHLEY" <kkeit...@redhat.com> >wrote: > >> On 07/28/2013 02:18 PM, Vijay Bellur wrote: >>> Hi All, >>> >>> There was a recent thread on fedora-devel about bloated glusterfs >>> dependency for qemu: >>> >>> >https://lists.fedoraproject.org/pipermail/devel/2013-July/186484.html >> >> Yes, but it's all died away after it was explained properly. >> >> >>> As of today, we have the following packages and respective primary >>> constituents: >>> >>> 1. glusterfs - contains all the common xlators, >>> libglusterfs, glusterfsd binary & glusterfs symlink to glusterfsd. >>> 2. glusterfs-rdma - rdma shared library >>> 3. glusterfs-geo-replication - geo-rep related objects >>> 4. glusterfs-fuse - fuse xlator >>> 5. glusterfs-server - server side xlators, config files >>> 6. glusterfs-api - libgfapi shared library >>> 7. glusterfs-resource-agents - OCF resource agents >>> 8. glusterfs-devel - Header files for libglusterfs >>> 9. glusterfs-api-devel - Header files for gfapi >>> >>> As far as qemu is concerned, qemu depends on glusterfs-api which in >turn >>> is dependent on glusterfs. Much of the apparent bloat is coming from >>> glusterfs package and one proposal for reducing the dependency >footprint >>> of consumers of libgfapi could be the following: >>> >>> a) Move glusterfsd and glusterfs symlink from 'glusterfs' to >>> 'glusterfs-server' >> >> We can't do that, it'll break the "client-side". You can't do a >client glusterfs mount without glusterfs at least..... >> >>> b) Package glusterfsd binary and glusterfs symlink in >'glusterfs-fuse' >> >> Okay, but the glusterfsd binary is only about 80k — that's tiny — and >the symlink is only a few bytes. >> >> And having the same bits in two RPMs could be a problem. I'll have to >try it for myself and see, or perhaps Niels already knows, but I'd be >worried that if I have both glusterfs-server and glusterfs-fuse >installed and I uninstall -fuse it might remove them and break things. >Not that anyone should uninstall -fuse without uninstalling -server. >> >>> 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? >> >> That's already in process for Fedora, and will soon be proposed for >the glusterfs.spec.in as well. >> >>> 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. >> >> Good suggestion. >> >> -- >> >> Kaleb >> >> _______________________________________________ >> Gluster-devel mailing list >> Gluster-devel@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/gluster-devel > >_______________________________________________ >Gluster-devel mailing list >Gluster-devel@nongnu.org >https://lists.nongnu.org/mailman/listinfo/gluster-devel
_______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
