Anonymous_User Absent Member.
Absent Member.
537 views

google-perftools and pprof packages on rhel 6.4 (x64)


While working on installing eDirectory on a RHEL 6.4 x64 system, the
installation program aborted due to a conflict between google-perftools
and an installed package called pprof. The system was installed based on
a kickstart template we use. This is a test machine, so, out of
curiosity, I removed the pprof package, continue with the installation
program and then ran yum update. I got a message that google-perftools
was going to be replaced by pprof. Is that Ok, or do I have to remove
everything that is requiring this pprof package?


--
celsolima
------------------------------------------------------------------------
celsolima's Profile: https://forums.netiq.com/member.php?userid=260
View this thread: https://forums.netiq.com/showthread.php?t=49410

Labels (1)
0 Likes
5 Replies
Anonymous_User Absent Member.
Absent Member.

Re: google-perftools and pprof packages on rhel 6.4 (x64)

I've never heard of pprof, and do not have RHEL nearby for testing. What
is it? What does it provide? What depends on it? Providing the output
of the following commands may be interesting:

Code:
--------------------
rpm -qi pprof
rpm -q --whatrequires pprof
rpm -q --provides pprof
rpm -ql pprof
--------------------

Hopefully from this we can determine why there is perceived to be a
conflict here.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: google-perftools and pprof packages on rhel 6.4 (x64)


The conflict is coming from the /usr/bin/pprof binary. It looks like
there is an updated version of the google-perftools package. I am going
to have to get back with you on on this. I need to find out how this
pprof package was installed on my system in the first place. I thought
it was part of the requirement for something else, but it was not. In
the mean time, this is what I have:

rpm -qi pprof
Name : pprof Relocations: (not
relocatable)
Version : 2.0 Vendor: Fedora Project
Release : 11.el6.3 Build Date: Wed 10 Jul 2013
03:21:04 PM CDT
Install Date: Mon 09 Dec 2013 01:26:02 PM CST Build Host:
buildvm-01.phx2.fedoraproject.org
Group : Development/Tools Source RPM:
gperftools-2.0-11.el6.3.src.rpm
Size : 171563 License: BSD
Signature : RSA/8, Thu 11 Jul 2013 12:30:39 PM CDT, Key ID
3b49df2a0608b895
Packager : Fedora Project
URL : http://code.google.com/p/gperftools/
Summary : CPU and Heap Profiler tool
Description :
Pprof is a heap and CPU profiler tool, part of the gperftools suite.

rpm -ql pprof
/usr/bin/pprof
/usr/share/man/man1/pprof.1.gz

rpm -q --whatrequires pprof
no package requires pprof

rpm -q --provides pprof
google-perftools = 2.0-11.el6.3 (Note that the version with
eDirectory is google-perftools-1.8.1-7.2)
pprof = 2.0-11.el6.3


--
celsolima
------------------------------------------------------------------------
celsolima's Profile: https://forums.netiq.com/member.php?userid=260
View this thread: https://forums.netiq.com/showthread.php?t=49410

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: google-perftools and pprof packages on rhel 6.4 (x64)

On 09/12/2013 20:14, celsolima wrote:

> The conflict is coming from the /usr/bin/pprof binary. It looks like
> there is an updated version of the google-perftools package. I am going
> to have to get back with you on on this. I need to find out how this
> pprof package was installed on my system in the first place. I thought
> it was part of the requirement for something else, but it was not.


Does "rpm -q --whatrequires /usr/bin/pprof" help indicate what required
the pprof binary?

HTH.
--
Simon
NetIQ Knowledge Partner

------------------------------------------------------------------------
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
------------------------------------------------------------------------
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: google-perftools and pprof packages on rhel 6.4 (x64)


What happened was the opposite of what I was thinking. The pprof package
was installed as an update for the google-perftools package installed
with eDirectory.

Among the channels my servers are getting updates from, there is a
channel called Extra Packages for Enterprise Linux
(epel-x86_64-server-6). That is the channel that contains the pprof
package.

Either the update channel has to be removed from the list of
repositories, or that particular package needs to be excluded during
patch updates.


--
celsolima
------------------------------------------------------------------------
celsolima's Profile: https://forums.netiq.com/member.php?userid=260
View this thread: https://forums.netiq.com/showthread.php?t=49410

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: google-perftools and pprof packages on rhel 6.4 (x64)

On 12/10/2013 08:04 AM, celsolima wrote:
>
> What happened was the opposite of what I was thinking. The pprof package
> was installed as an update for the google-perftools package installed
> with eDirectory.


Um........ RHEL, or your use of it, is perhaps broken then.

> Among the channels my servers are getting updates from, there is a
> channel called Extra Packages for Enterprise Linux
> (epel-x86_64-server-6). That is the channel that contains the pprof
> package.


That's nice, but RHEL (if it's like SLES anyway) should be smart enough to
realize that one package from one vendor is not an upgrade to another
package from another vendor. Maybe something's quirky about
Novell/NetIQ's original package, but this really should only happen when
the package is from the same vendor. It seems highly unlikely that the
Novell/NetIQ build would have a vendor of 'Fedora Project or a signature
from the same key as your pprof package from Fedora, so something is amiss.

> Either the update channel has to be removed from the list of
> repositories, or that particular package needs to be excluded during
> patch updates.


See above. Assuming you're patching your system and not using calls that
would upgrade (and thus allow a change of vendor) this just seems wrong.
In the SLES world the 'zypper' command has a patch option and an upgrade
option. The patch option does patches, and the upgrade option (without a
limitation to just patches) will change vendors of software if it detects
"newer" stuff (as much as that detection is possible). I'm guessing there
is an equivalent option with 'yum' but I cannot verify that.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.