[Gluster-devel] RPM re-structuring

[Anand Avati]

On Wed, Aug 14, 2013 at 12:25 AM, Deepak C Shetty <
deepakcs at linux.vnet.ibm.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> 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
>
>  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.
>

Actually this *wasnt* what we discussed. glusterfs-api was supposed to
depend on glusterfs-libs *ONLY*. This is because it has a linking (hard)
relationship with glusterfs-libs, and glusterfs.rpm is only a run-time
dependency - everything here is dlopen()ed.



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

I think this was exactly what we concluded. That a user would need to
install glusterfs rpm if they wanted to store VM images on gluster
(independent of the fact that qemu was linked with glusterfs-api). Do you
see a problem with this?

Avati


> 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
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130814/6862ba13/attachment-0001.html>