Re: RPM re-structuring

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

 



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@xxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx
https://lists.nongnu.org/mailman/listinfo/gluster-devel



Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
https://lists.nongnu.org/mailman/listinfo/gluster-devel

[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