Re: RPM re-structuring

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux