[Gluster-devel] RPM re-structuring

[Vijay Bellur]

On 07/29/2013 12:37 AM, Anand Avati wrote:
>
>
>
> On Sun, Jul 28, 2013 at 12:02 PM, Vijay Bellur <vbellur at redhat.com
> <mailto:vbellur at redhat.com>> wrote:
>
>     On 07/29/2013 12:18 AM, Anand Avati wrote:
>
>
>
>
>         On Sun, Jul 28, 2013 at 11:18 AM, Vijay Bellur
>         <vbellur at redhat.com <mailto:vbellur at redhat.com>
>         <mailto:vbellur at redhat.com <mailto:vbellur at redhat.com>>> 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
>
>
>         <https://lists.fedoraproject.__org/pipermail/devel/2013-July/__186484.html
>         <https://lists.fedoraproject.org/pipermail/devel/2013-July/186484.html>>
>
>              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'
>
>
>
>         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 <http://mount.glusterfs.in>
>         <http://mount.glusterfs.in>
>
>
>     With this model, glusterfsd is part of both -server and -fuse. I
>     don't like this idea entirely, for a different scheme see below.
>
>
>
>         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
>         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.
>
>
>     I like the idea about users of qemu not having to do with
>     non-required glusterfs cruft but with this model we still have
>     glusterfsd binary being pulled in for consumers who want libgfapi alone.
>
>
> How? libgfapi depends only on glusterfs-libs. Whereas glusterfsd is in
> glusterfs rpm.

In the scenario when somebody tries to use the gluster client xlators 
via libgfapi, we would end up installing glusterfsd still. Do we really 
need that to happen?

-Vijay