Thanks for this information Kaleb.
I'll check the changes I've done till now with the older versions of the libraries. I think I'm going to need at least the 0.8.* release of liburcu, as some new apis were introduced in it, which I'm using. I'll post the outcome of my tests back here.
For a start, I collected the various versions of liburcu (userspace-rcu in some) available in the different distros. This list is based on the distros for which we provide community built packages and test on.
- Fedora 21 - 0.8.1 (0.8.5 in testing but stuck due to some breakages)
- Fedora 20 - 0.7.7 (0.8.5 in testing but stuck due to some breakages)
- EL7 - 0.7.9
- EL6 - 0.7.7
- Debian Wheezy - 0.6.7
- Debian Jessie - 0.8.5 (in testing)
- Ubuntu Precise - 0.6.7
- Ubuntu Trusty - 0.7.12
- Ubuntu Utopic - 0.8.4
- Netbsd - 0.8.6
- Freebsd - 0.7.7
The list doesn't look too good.
~kaushal
On Fri, Jan 30, 2015 at 6:30 PM, Kaleb KEITHLEY <kkeithle@xxxxxxxxxx> wrote:
Hi,
Just FYI, what you propose is called bundling in Fedora packaging parlance, and Fedora's packaging guidelines forbid bundling. It is possible to get an exception granted, but it's not safe to presume that an exception will be granted.
(For downstream this is a non-issue, but here on gluster-devel we're not concerned with downstream.)
You either need to convince the maintainers of liburcu to update to the newer versions everywhere, or you need to implement using the oldest version on the platforms you intend to support. And if this is too onerous, e.g. to use what's in (RH)EL5, then it's another argument in favor of dropping support for (RH)EL5. (The other argument is that python on RHEL5 is too old for geo-rep.)
In short, those of use who package gluster in Fedora would be, however reluctantly, required to vote against doing this. I recommend contacting the liburcu maintainers in Fedora/EPEL and see if you can't convince them to update to the newest version.
Regards,
--
Kaleb
/30/2015 12:09 PM, Deepak Shetty wrote:
On Thu, Jan 29, 2015 at 5:05 PM, Kaushal M <kshlmster@xxxxxxxxx_______________________________________________<mailto:kshlmster@xxxxxxxxx>> wrote:
Hi all,
I had started a thread previously on the efforts we are undertaking
to improve thread synchronization in GlusterD [1]. I had mentioned
that we will be using RCU for synchronization and the userspace RCU
library (liburcu) [2] for implementation.
I am now in a almost in a position to submit changes to Gerrit for
review. But, I have an obstacle of making liburcu available on the
jenkins slaves.
I have begun development using the 0.8.6 version of liburcu, which
is the latest stable release. EPEL has liburcu packages for CentOS 6
and 7, but they are the of the older 0.7.* versions. Fedora has
packages more recent packages, but they are still older, 0.8.1. [3].
Considering the above situation with binary packages, I'm
considering adding liburcu into the GlusterFS tree as a part of
/contrib. This will be similar in vein to the argp-standalone library.
liburcu is licensed under LGPL-v2.1, so I don't think there is going
to be any problem including it. But IANAL, so I would like to know
of if this would if this is okay from a legal perspective.
I'll add the liburcu source to our tree and push the change for
review. I'm not really familiar with autotools, so I'll need some
help integrating it into our build system. I'll update the list when
I have pushed the change for review.
How do you intend to add, as a git submodule or ?
I had worked on GNU autotools in the past, but frankly don't remember
much of it. If any help is needed I can try, or can get someone to help
from my ex-company :)
thanx,
deepak
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
