[Gluster-devel] Integrating liburcu source into the glusterfs source tree

[Kaushal M]

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 at redhat.com> 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 at gmail.com
>> <mailto:kshlmster at gmail.com>> 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 at gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150202/510efa8e/attachment.html>