[Pacemaker] epel version of rpm pacemaker-1.1.7

[Andrew Beekhof]

On Wed, May 16, 2012 at 9:20 AM, Andrew Beekhof <andrew at beekhof.net> wrote:
> On Tue, May 15, 2012 at 10:57 PM, Trevor Hemsley <themsley at voiceflex.com> wrote:
>> On 15/05/12 13:32, Andrew Beekhof wrote:
>>> On Tue, May 15, 2012 at 8:36 PM, Trevor Hemsley <themsley at voiceflex.com> wrote:
>>>> On 15/05/12 05:24, Andrew Beekhof wrote:
>>>>> On Tue, May 15, 2012 at 4:48 AM, Larry Brigman <larry.brigman at gmail.com> wrote:
>>>>>> On Tue, May 8, 2012 at 9:45 PM, Andrew Beekhof <andrew at beekhof.net> wrote:
>>>>>>> On Wed, May 9, 2012 at 6:43 AM, Larry Brigman <larry.brigman at gmail.com> wrote:
>>>>>>>> I must be coming to the party late.  I just noticed that 1.1.7 version
>>>>>>>> of pacemaker is out.
>>>>>>>> We are running 1.1.5 on centos5 and would like to upgrade to 1.1.7 but I
>>>>>>>> am not finding the rpm.
>>>>>>>>
>>>>>>>> Is that not getting built and pushed to rpm-next/epel5 tree any more?
>>>>>>>> Is there plans to do build it?
>>>>>>> I believe glib on epel5 is too old to build 1.1.7 there.
>>>>>>> Is there something preventing you from using a rhel-6 derivative?
>>>>>> Existing applications, tools and libraries that have not been tested on RHEL-6,
>>>>>> plus multiple systems needing to be upgraded to RHEL-6 from RHEL-5 that
>>>>>> has yet to be tested.
>>>>> Ok.
>>>>>
>>>>> If there is sufficient interest (as gauged by
>>>>> http://beekhof.polldaddy.com/s/rhel-versions ), I will re-activate the
>>>>> epel-5 repo and include a more recent version of glib2.
>>>>> Please get the word out :-)
>>>> Wouldn't it be better to fix the code to not use this function rather
>>>> than update a core el5 package?
>>>>
>>>>
>>> No.
>>> The function has value, otherwise it wouldn't have been added to GLib
>>> nor would we be using it.
>>>
>>> Preventing progress in an upstream project because someone, somewhere,
>>> is running a VAX isn't a tenable position.
>> I ask because I have successfully patched other projects that thought
>> they needed to use this same glib API call to work with a different and
>> almost identical call. It requires about 6 extra lines of code and is
>> not that much more complicated. Yes, the one you are using is simpler
>> and more direct but RHEL5 still has 5 years of life left in it
>
> 5 years seems a bit long, but I can't confirm that right now.
> On the flip side, your version of glib dates back to RHEL4 which makes
> it nearly 6 years old.
>
>> and
>> abandoning it because of this one call seems a little premature.
>> Supplying a replacement core package is also not ideal given how many
>> other packages depend on this particular one.
>>
>> Will you take a patch if I can find the time to produce one?
>
> Sure. Someone tried already IIRC, perhaps it just needs to be updated.

Although I'd also like to start using g_unix_signal_add() which appeared in 2.30
As a general rule, its not a good idea to use custom versions of standard APIs