[Gluster-devel] RPM re-structuring

[Vijay Bellur]

On 07/29/2013 12:49 AM, Anand Avati wrote:
>
>
>                  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?
>
>
>
> Isn't the concern that someone who is not interested in using glusterfs
> is now forced into removing qemu, libvirt and the whole virt shebang
> when trying to uninstall glusterfs rpm? glusterfsd coming along when
> common xlators (client xlators) are installed is probably not a big
> deal.. That would happen only for users who are interested in glusterfs
> anyways.
>

Yes, qemu and related packages being removed while trying to uninstall 
glusterfs is the larger concern. I did see one response which questioned 
what glusterfsd was doing in the client package.

(https://lists.fedoraproject.org/pipermail/devel/2013-July/186504.html).

Kaleb has responded explaining the symlink'ing between glusterfsd and 
glusterfs. That might suffice for now and we can move to this model 
which addresses the larger concern.

-Vijay