On 02/10/2011 12:37 AM, Ned Slider wrote:
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@fnal.gov:
<quote> On Wed, Feb 9, 2011 at 11:27 AM, Ewan Mac Mahon<ewan@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@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.
This is correct, CentOS would add an updated package somewhere (our people.centos.org site or the centos-testing repository would be the likely places).
We want our release to be the same source code where ever possible ... only changing things as required to meet trademark restrictions.
I can't speak to how SL will do it.