Hello world!
I'm having a very similar problem installing *ntop* package from epel, which
I think needs *rrdtool-1.2.30-2.sl4*, since the yum installation procces ask
me for *librrd_th.so.2*, but I'm running SL53, so the available package for
this SL version is *rrdtool-1.3.9-2.sl5*.
Should I download and install the version I need by hand, install with rpm
and block yum to update rrdtool??
Thanks a lot in advance!!
Fernando.
Some information about my problem:
# lsb_release -a
LSB Version:
:core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: ScientificSL
Description: Scientific Linux SL release 5.3 (Boron)
Release: 5.3
Codename: Boron
# uname -rimvr
2.6.18-164.11.1.el5 #1 SMP Wed Jan 20 01:05:28 EST 2010 i686 i386
# yum list rrdtool ntop
Loaded plugins: kernel-module, priorities
2272 packages excluded due to repository priority protections
Available Packages
ntop.i386
3.3.9-7.el5 epel
rrdtool.i386
1.3.9-2.sl5 sl-security
# yum deplist ntop | grep rrd
dependency: librrd_th.so.2
dependency: librrd_th.so.2
dependency: librrdPlugin-3.3.8.so
dependency: librrdPlugin-3.2.so
dependency: libmyrrd-3.2.so
dependency: librrd_th.so.2
dependency: librrdPlugin-3.3.so
dependency: librrd_th.so.4
* provider: rrdtool.i386 1.3.9-2.sl5* -> Looks like this package is enough
for ntop but...
dependency: librrdPlugin-3.3.8.so
dependency: librrdPlugin-3.3.6.so
dependency: librrd_th.so.2
]# yum install ntop
Loaded plugins: kernel-module, priorities
2272 packages excluded due to repository priority protections
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package ntop.i386 0:3.3.9-7.el5 set to be updated
--> Processing Dependency: libGeoIP.so.1 for package: ntop
--> Processing Dependency: librrd_th.so.2 for package: ntop
--> Processing Dependency: graphviz for package: ntop
--> Running transaction check
---> Package geoip.i386 0:1.4.5-1.el5.rf set to be updated
---> Package graphviz.i386 0:2.24.0-1.el5.sl set to be updated
---> Package ntop.i386 0:3.3.9-7.el5 set to be updated
--> Processing Dependency: librrd_th.so.2 for package: ntop
--> Finished Dependency Resolution
ntop-3.3.9-7.el5.i386 from epel has depsolving problems
--> Missing Dependency: librrd_th.so.2 is needed by package
ntop-3.3.9-7.el5.i386 (epel)
Beginning Kernel Module Plugin
Finished Kernel Module Plugin
Error: Missing Dependency: librrd_th.so.2 is needed by package
ntop-3.3.9-7.el5.i386 (epel)
You could try using --skip-broken to work around the problem
You could try running: package-cleanup --problems
package-cleanup --dupes
rpm -Va --nofiles --nodigest
Thanks again!
On Mon, Feb 8, 2010 at 14:33, Steve Traylen <steve.tray...@cern.ch> wrote:
> 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
>>
>
>
--
---------------------------------------------------------------------------------------------------------
Fernando Campos Del Pozo
Becario Super-Computación - Departamento de Física Teórica
Facultad de Ciencias / Módulo 15 (C-XI) / Despacho 512
Tlf.: +34-914974893
e-mail: fernando.cam...@uam.es
