On 2/1/10 4:27 PM, Ewan Mac Mahon wrote:
> On Thu, Dec 10, 2009 at 09:12:56AM -0600, Troy Dawson wrote:
>> Hello,
>> We are adding a new package to SLF 4 and 5, rrdtool.
>>
>> These packages will go out on Tuesday, December 15, 2009
>>
>> We have already done alot of testing and debugging, but we would like it
>> if others tested it would be good.
>>
>> Note: We have updated the spec file so that these packages are
>> compatible with both epel and dag (which packaged rrdtool differently
>> from each other)
>>
> This seems to cause rather bad breakage with the EPEL builds of ganglia,
> and possibly anything else that uses the rrdtool libraries. The current
> EPEL ganglia links against librrd.so.2, which is in the EPEL build of
> rrdtool as a symlink in the usual manner:
>
>   # ls -l /usr/lib64/librrd.so.2
>   lrwxrwxrwx 1 root root 16 Feb  1 14:52 /usr/lib64/librrd.so.2 ->  librrd.so.2.0.13
>
> The new SL rrdtool packages however, have a different library soname:
>
>   # ls -l /usr/lib64/librrd.so.4
>   lrwxrwxrwx 1 root root 15 Feb  1 15:14 /usr/lib64/librrd.so.4 ->  librrd.so.4.0.8
>
> Depending on the installation order, this either makes it impossible to
> install EPEL's ganglia (if the SL rrdtool is already installed) or to
> update from the sl-security repo if the EPEL rrdtool and ganglia
> packages are already installed.
>
> Given the reference to making the SL packages 'compatible with both epel
> and dag', I'm guessing this is not intended behaviour. I'm not sure how
> best to fix this, but the simplest approach may be to pull ganglia into
> SL and rebuild it against the newer rrdtool.

Would it not be easier to just remove rrdtool from SL. Following on from 
fixing this way you would eventually have to replace everything in EPEL.

>
> Ewan