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
