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 <steve.tray...@cern.ch
<mailto: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 <mailto:fernando.cam...@uam.es>
--
__________________________________________________
Troy Dawson daw...@fnal.gov (630)840-6468
Fermilab ComputingDivision/LSCS/CSI/USS Group
__________________________________________________
