On Wed, May 16, 2012 at 9:20 AM, Andrew Beekhof <and...@beekhof.net> wrote: > On Tue, May 15, 2012 at 10:57 PM, Trevor Hemsley <thems...@voiceflex.com> > wrote: >> On 15/05/12 13:32, Andrew Beekhof wrote: >>> On Tue, May 15, 2012 at 8:36 PM, Trevor Hemsley <thems...@voiceflex.com> >>> wrote: >>>> On 15/05/12 05:24, Andrew Beekhof wrote: >>>>> On Tue, May 15, 2012 at 4:48 AM, Larry Brigman <larry.brig...@gmail.com> >>>>> wrote: >>>>>> On Tue, May 8, 2012 at 9:45 PM, Andrew Beekhof <and...@beekhof.net> >>>>>> wrote: >>>>>>> On Wed, May 9, 2012 at 6:43 AM, Larry Brigman <larry.brig...@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 _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
