On Mon, Jul 29, 2013 at 09:56:09AM -0700, Joe Julian wrote: > 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. Thats what I would suggest as well. rot-13 and other unused xlators should probably not be built by default at all, or maybe we can add them in a glusterfs-extras package if people want to be able to install the binaries easily (but I honestly do not see a real use-case for that). Niels > > Jay Vyas <jayunit100@xxxxxxxxx> 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" <kkeithle@xxxxxxxxxx> > >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@xxxxxxxxxx > >> https://lists.nongnu.org/mailman/listinfo/gluster-devel > > > >_______________________________________________ > >Gluster-devel mailing list > >Gluster-devel@xxxxxxxxxx > >https://lists.nongnu.org/mailman/listinfo/gluster-devel > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > https://lists.nongnu.org/mailman/listinfo/gluster-devel -- Niels de Vos Sr. Software Maintenance Engineer Support Engineering Group Red Hat Global Support Services
