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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] >> http://www.gluster.org/mailman/listinfo/gluster-devel >> >> >
_______________________________________________ Gluster-devel mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-devel
