Fernando Campos wrote:
Thanks for answering!!
I have a question: It's not suppose that SL4 stands for RHEL4 and SL5
for RHEL5??
Correct
Because I found the version 1.2.27 of rrdtool in the el5 section of EPEL:
http://download.fedora.redhat.com/pub/epel/5/i386/repoview/rrdtool.html
Could be that the appropriate version of rrdtool for SL5 is still 1.2.X???
The problem is that the dag repository was at version 1.3, and is now at
version 1.4.
So, if we only had version 1.2, then all of our dag repository users
would be having problems.
I have to admit, that when someone asked to put it in, and I agreed, I
had no idea about all the dependancies that were involved. Not that
rrdtool has dependencies, but all the other packages that depend on it.
Troy
Have no idea about repos administration, so it's just a newbie question...
Anyway, I downloaded and installed the version 1.2.27 of rrdtool and now
yum install ntop worked, so thanks!! :)
On Mon, Feb 8, 2010 at 18:49, Troy Dawson <[email protected]
<mailto:[email protected]>> wrote:
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> <http://librrdPlugin-3.3.8.so>
dependency: librrdPlugin-3.2.so <http://librrdPlugin-3.2.so>
<http://librrdPlugin-3.2.so>
dependency: libmyrrd-3.2.so <http://libmyrrd-3.2.so>
<http://libmyrrd-3.2.so>
dependency: librrd_th.so.2
dependency: librrdPlugin-3.3.so <http://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> <http://librrdPlugin-3.3.8.so>
dependency: librrdPlugin-3.3.6.so
<http://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> <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
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
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: [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
--
__________________________________________________
Troy Dawson [email protected] <mailto:[email protected]> (630)840-6468
Fermilab ComputingDivision/LSCS/CSI/USS Group
__________________________________________________
--
---------------------------------------------------------------------------------------------------------
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: [email protected] <mailto:[email protected]>
--
__________________________________________________
Troy Dawson [email protected] (630)840-6468
Fermilab ComputingDivision/LSCS/CSI/USS Group
__________________________________________________
