[Gluster-devel] RPM re-structuring

[Deepak C Shetty]

On 08/14/2013 12:55 PM, Deepak C Shetty 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>> 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

See http://paste.fedoraproject.org/31972/64604451/
which was recorded on a F19 system

>
> 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/553347ad/attachment-0001.html>