[Pacemaker] epel version of rpm pacemaker-1.1.7

[Trevor Hemsley]

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 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?