On 10/02/11 02:05, Larry Vaden wrote: > In order to avoid a cross post, the following background quote is from > SCIENTIFIC-LINUX-USERS at fnal.gov: > > <quote> > On Wed, Feb 9, 2011 at 11:27 AM, Ewan Mac Mahon<ewan at macmahon.me.uk> wrote: >> >> I'm a little bit hazy on the details, but there are some slides from the >> meeting here[1]: >> http://indico.cern.ch/getFile.py/access?contribId=8&sessionId=1&resId=1&materialId=slides&confId=106641 > > On Wed, Feb 9, 2011 at 12:41 PM, Chris Jones > <christopher.rob.jones at cern.ch> wrote: >> >> I would say a bug in tcmalloc, not SL or RHEL. See for instance >> >> <http://code.google.com/p/google-perftools/issues/detail?id=305> >> >> The fix is to move to google perftools 1.7 > > </quote> > > Because of a problem with not running the current BIND release a > couple of weeks ago, I would like to ask: > > a) is RedHat likely to choose to backport the fix to 1.6 or will it > adopt 1.7 or leave as is until 5.7 or later as it has done with BIND? > > b) will Centos and/or SL follow RH exactly or will their approaches differ? > > IOW, how far does the "binary compatiblity" policy extend? > Bug for bug - if the bug is in RHEL-5.6 then it will be in CentOS too. If it's important to you, file a bug upstream with Red Hat and get it fixed. The fix will naturally flow back downstream to CentOS. Of course CentOS does have the freedom to do things differently to Red Hat if they want to, but if they do generally it will be outside of the main base/updates) repositories.