[Pacemaker] epel version of rpm pacemaker-1.1.7

[Andrew Beekhof]

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.