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.

Ewan