Re: [Gluster-devel] RPM re-structuring

[Kaleb S. KEITHLEY]

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