[Gluster-devel] RPM re-structuring

[Deepak C Shetty]

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>> 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
>
>     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>
>
> 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.

Looks like even after the re-packaging.. the original problem is still 
there !
Post re-strucuring ( i am on F19 with updates-testing repo enabled)

gluserfs-api has dep on -libs and glusterfs
So when User install glusterfs-api, it pulls in -libs and glusterfs

This is correct, since w/o glusterfs rpm we won't have a working qemu 
gluster backend. Just allowing qemu to execute by way of installing-libs 
and -api only won't help, since once qemu executes and someone tries 
qemu w/ gluster backend.. things will fail unless User has installed 
glusterfs rpm (which has all the client xlators)

So today ...
yum install glusterfs-api brings in glusterfs-libs and glusterfs
which sounds correct to get a working system with qemu gluster backend.

Later...
yum remove glusterfs
removes glusterfs-api which has a reverse dep on qemu, hence libvirt 
hence the entire virt stack goes down

which was the original problem reported in the fedora devel list @
https://lists.fedoraproject.org/pipermail/devel/2013-July/186484.html

and that unfortunately is still there, even after -libs was created as a 
separate rpm as part of this effort!

thanx,
deepak

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130814/99d51a75/attachment-0001.html>