[Gluster-devel] RPM re-structuring

[Joe Julian]

I disagree. Since the cli will not build a volume with it, it doesn't need to be in a  package. Since its value is purely academic, only the source code matters, and it will still be in the git repo and the src tarball.

Jay Vyas <jayunit100 at gmail.com> wrote:
>minor point: rot-13 is a good one for learning and playing with
>gluster.  i would suggest keeping it in the releases.!
>
>
>On Jul 29, 2013, at 7:21 AM, "Kaleb S. KEITHLEY" <kkeithle at redhat.com>
>wrote:
>
>> On 07/28/2013 02:18 PM, Vijay Bellur 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
>> 
>> Yes, but it's all died away after it was explained properly.
>> 
>> 
>>> 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'
>> 
>> We can't do that, it'll break the "client-side". You can't do a
>client glusterfs mount without glusterfs at least.....
>> 
>>> b) Package glusterfsd binary and glusterfs symlink in
>'glusterfs-fuse'
>> 
>> Okay, but the glusterfsd binary is only about 80k — that's tiny — and
>the symlink is only a few bytes.
>> 
>> And having the same bits in two RPMs could be a problem. I'll have to
>try it for myself and see, or perhaps Niels already knows, but I'd be
>worried that if I have both glusterfs-server and glusterfs-fuse
>installed and I uninstall -fuse it might remove them and break things.
>Not that anyone should uninstall -fuse without uninstalling -server.
>> 
>>> c) Kaleb mentioned about removing geo-replication objects from
>>> 'glusterfs' and having them in 'glusterfs-geo-replication' only. I
>think
>>> that might help unless we are breaking something in geo-replication
>by
>>> doing so. Do we remember the original intent behind packaging
>>> geo-replication objects in the 'glusterfs' package?
>> 
>> That's already in process for Fedora, and will soon be proposed for
>the glusterfs.spec.in as well.
>> 
>>> d) Remove mac-compat.so, rot-13.so, symlink-cache.so from
>'glusterfs'.
>>> As practically nobody uses these translators today, I don't see much
>>> value in packaging them.
>> 
>> Good suggestion.
>> 
>> -- 
>> 
>> Kaleb
>> 
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>_______________________________________________
>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/20130729/9c241c98/attachment-0001.html>