[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gluster-devel] RPM re-structuring

From: Vijay Bellur
Subject: [Gluster-devel] RPM re-structuring
Date: Sun, 28 Jul 2013 23:48:32 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6

Hi All,

There was a recent thread on fedora-devel about bloated glusterfs dependency for qemu:

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'
b) Package glusterfsd binary and glusterfs symlink in 'glusterfs-fuse'
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? d) Remove,, from 'glusterfs'. As practically nobody uses these translators today, I don't see much value in packaging them.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]