Sender: |
|
Date: |
Thu, 10 Feb 2011 11:23:40 +0100 |
MIME-version: |
1.0 |
Reply-To: |
|
Content-type: |
text/plain; format=flowed; charset=ISO-8859-1 |
Subject: |
|
From: |
|
In-Reply-To: |
|
Content-transfer-encoding: |
7BIT |
Comments: |
|
Parts/Attachments: |
|
|
On 02/10/2011 02:59 AM, Larry Vaden wrote:
> On Wed, Feb 9, 2011 at 11:27 AM, Ewan Mac Mahon<[log in to unmask]> 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
> THANKS!
>
> On Wed, Feb 9, 2011 at 12:41 PM, Chris Jones
> <[log in to unmask]> 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
> 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?
google-perftools comes from epel, not rhel. What the epel
google-perftools maintainer will do is not easy to judge. I don't know
how to interpret https://bugzilla.redhat.com/show_bug.cgi?id=675376.
But since this is epel and not rhel, I see no relation to the 5.7
release. I would expect that epel maintainers react to this
incompatibility between google-perftools and the current rhel release.
But then again i have not found an epel bugzilla entry that explicitly
mentions the problem.
Matthias
> b) will Centos and/or SL follow RH exactly or will their approaches differ?
>
> IOW, how far does the "binary compatiblity" policy extend?
>
> kind regards/ldv
|
|
|