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