[Gluster-devel] RPM re-structuring

[Niels de Vos]

On Mon, Jul 29, 2013 at 09:56:09AM -0700, Joe Julian wrote:
> 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.

Thats what I would suggest as well. rot-13 and other unused xlators 
should probably not be built by default at all, or maybe we can add them 
in a glusterfs-extras package if people want to be able to install the 
binaries easily (but I honestly do not see a real use-case for that).

Niels


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

> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel


-- 
Niels de Vos
Sr. Software Maintenance Engineer
Support Engineering Group
Red Hat Global Support Services