Looks like we didn't get enough testing done, and maybe rrdtool doesn't
really need to be in the plain SL release.
I have no problem pulling it out of the release and having people just
install it from dag or EPEL, whichever they prefer. Since it hasn't
gotten into any final release, this isn't that much of a problem, I just
need to take it out of the repositories.
Does anyone *really* need it in the release? Is there any real reasons
why people can't get it from dag and/or EPEL after they are installed?
Troy
p.s. Just so you know, we didn't test it with every EPEL package. When
I said that "these packages are compatible with both epel and dag" I was
meaning the rrdtool package. It was packaged in the EPEL fashion and
naming convention, with provides statements so that it worked and
updated corrected with the dag repository.
Fernando Campos wrote:
> 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 <http://librrdPlugin-3.3.8.so>
> dependency: librrdPlugin-3.2.so <http://librrdPlugin-3.2.so>
> dependency: libmyrrd-3.2.so <http://libmyrrd-3.2.so>
> dependency: librrd_th.so.2
> dependency: librrdPlugin-3.3.so <http://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 <http://librrdPlugin-3.3.8.so>
> dependency: librrdPlugin-3.3.6.so <http://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 <http://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 <[log in to unmask]
> <mailto:[log in to unmask]>> 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: [log in to unmask] <mailto:[log in to unmask]>
--
__________________________________________________
Troy Dawson [log in to unmask] (630)840-6468
Fermilab ComputingDivision/LSCS/CSI/USS Group
__________________________________________________
|