Hi.
I've found inconstancy between output of repoquery and rpm. I was looking forward towards apache php 5.4 module which must provided by some package SCL (can someone tell me?).
rpm -qf /etc/httpd/modules/mod_proxy.so httpd-2.2.15-29.el6.centos.x86_64 repoquery -qf /etc/httpd/modules/mod_proxy.so
so repoquery results in no output
yum list installed httpd Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * c6-media: Installed Packages httpd.x86_64 2.2.15-29.el6.centos @c6-media
repoquery -qa httpd httpd-0:2.2.15-29.el6.centos.x86_64
No wonder libphp5.so results in no output.
On Tue, Sep 16, 2014 at 10:16:37AM +0530, dE wrote:
Hi.
I've found inconstancy between output of repoquery and rpm. I was looking forward towards apache php 5.4 module which must provided by some package SCL (can someone tell me?).
rpm -qf /etc/httpd/modules/mod_proxy.so httpd-2.2.15-29.el6.centos.x86_64 repoquery -qf /etc/httpd/modules/mod_proxy.so
so repoquery results in no output
yum list installed httpd Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile
- c6-media:
Installed Packages httpd.x86_64 2.2.15-29.el6.centos @c6-media
repoquery -qa httpd httpd-0:2.2.15-29.el6.centos.x86_64
No wonder libphp5.so results in no output.
The 'httpd' package actually contains the mod_proxy.so as /usr/lib64/httpd/modules/mod_proxy.so. Running 'repoquery -f /usr/lib64/httpd/modules/mod_proxy.so' will generate the correct response.
RPM, on the other hand, has the benefit of having a local filesystem with the actual files installed.
One of the first things that the 'rpm' command does is stat() the path /etc/httpd/modules, discover it's a symlink, and then run the actual path /usr/lib64/httpd/modules/mod_proxy.so through the RPM database. The command is going to pass the 'real' location (as best it can find) for any query with file paths. 'repoquery' doesn't have the benefit of having the package installed, so it can't perform this local lookup. It has to rely only on what the package manifest lists.
On Tue, September 16, 2014 8:49 am, Jonathan Billings wrote:
On Tue, Sep 16, 2014 at 10:16:37AM +0530, dE wrote:
Hi.
I've found inconstancy between output of repoquery and rpm. I was looking forward towards apache php 5.4 module which must provided by some package SCL (can someone tell me?).
rpm -qf /etc/httpd/modules/mod_proxy.so httpd-2.2.15-29.el6.centos.x86_64 repoquery -qf /etc/httpd/modules/mod_proxy.so
so repoquery results in no output
yum list installed httpd Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile
- c6-media:
Installed Packages httpd.x86_64 2.2.15-29.el6.centos @c6-media
repoquery -qa httpd httpd-0:2.2.15-29.el6.centos.x86_64
No wonder libphp5.so results in no output.
The 'httpd' package actually contains the mod_proxy.so as /usr/lib64/httpd/modules/mod_proxy.so. Running 'repoquery -f /usr/lib64/httpd/modules/mod_proxy.so' will generate the correct response.
RPM, on the other hand, has the benefit of having a local filesystem with the actual files installed.
One of the first things that the 'rpm' command does is stat() the path /etc/httpd/modules, discover it's a symlink, and then run the actual path /usr/lib64/httpd/modules/mod_proxy.so through the RPM database. The command is going to pass the 'real' location (as best it can find) for any query with file paths. 'repoquery' doesn't have the benefit of having the package installed, so it can't perform this local lookup. It has to rely only on what the package manifest lists.
That's an interesting thing. Ideally I would prefer the query command do exactly what I asked, if I asked about existence of some path, I would like to check that path and tell me which package brought it to my box. In an idiotic situation when symlink came with one package and actual file symlink points to from another, when I query symlink, I'd like to get an answer about it. Am I missing something?
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Tue, Sep 16, 2014 at 09:01:53AM -0500, Valeri Galtsev wrote:
That's an interesting thing. Ideally I would prefer the query command do exactly what I asked, if I asked about existence of some path, I would like to check that path and tell me which package brought it to my box. In an idiotic situation when symlink came with one package and actual file symlink points to from another, when I query symlink, I'd like to get an answer about it. Am I missing something?
Without looking at the source itself, I can't be sure, but I suspect that 'rpm' first did look for the given path in the RPM database, failed to find anything, and then performed the equivalent of 'readlink -f /etc/httpd/modules/mod_proxy.so', canonicalizing the path, then searching again.
I'm not sure what you're describing in your example. RPMs can provide symlinks, and they show up in the package manifest. If a package included a symlink to a directory or file owned by another package, I'm sure that querying the path to the symlink would return the package that includes the symlink, not the package that includes what the link pointed to.
On Tue, September 16, 2014 9:58 am, Jonathan Billings wrote:
On Tue, Sep 16, 2014 at 09:01:53AM -0500, Valeri Galtsev wrote:
That's an interesting thing. Ideally I would prefer the query command do exactly what I asked, if I asked about existence of some path, I would like to check that path and tell me which package brought it to my box. In an idiotic situation when symlink came with one package and actual file symlink points to from another, when I query symlink, I'd like to get an answer about it. Am I missing something?
Without looking at the source itself, I can't be sure, but I suspect that 'rpm' first did look for the given path in the RPM database, failed to find anything, and then performed the equivalent of 'readlink -f /etc/httpd/modules/mod_proxy.so', canonicalizing the path, then searching again.
I'm not sure what you're describing in your example. RPMs can provide symlinks, and they show up in the package manifest. If a package included a symlink to a directory or file owned by another package, I'm sure that querying the path to the symlink would return the package that includes the symlink, not the package that includes what the link pointed to.
Oh, great, then I'm happy again. As that is what I expect as an answer to my query. Apparently I failed to read the original post correctly ;-)
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 09/16/14 19:19, Jonathan Billings wrote:
On Tue, Sep 16, 2014 at 10:16:37AM +0530, dE wrote:
Hi.
I've found inconstancy between output of repoquery and rpm. I was looking forward towards apache php 5.4 module which must provided by some package SCL (can someone tell me?).
rpm -qf /etc/httpd/modules/mod_proxy.so httpd-2.2.15-29.el6.centos.x86_64 repoquery -qf /etc/httpd/modules/mod_proxy.so
so repoquery results in no output
yum list installed httpd Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile
- c6-media:
Installed Packages httpd.x86_64 2.2.15-29.el6.centos @c6-media
repoquery -qa httpd httpd-0:2.2.15-29.el6.centos.x86_64
No wonder libphp5.so results in no output.
The 'httpd' package actually contains the mod_proxy.so as /usr/lib64/httpd/modules/mod_proxy.so. Running 'repoquery -f /usr/lib64/httpd/modules/mod_proxy.so' will generate the correct response.
RPM, on the other hand, has the benefit of having a local filesystem with the actual files installed.
One of the first things that the 'rpm' command does is stat() the path /etc/httpd/modules, discover it's a symlink, and then run the actual path /usr/lib64/httpd/modules/mod_proxy.so through the RPM database. The command is going to pass the 'real' location (as best it can find) for any query with file paths. 'repoquery' doesn't have the benefit of having the package installed, so it can't perform this local lookup. It has to rely only on what the package manifest lists.
Yeah, but that's the problem running repoquery -f /usr/lib64/httpd/modules/mod_proxy.so does not give any output.
rpm is actual package manage working under yum, so it job is to maintain the installed package, but I would expect repoquery (which's a part of yum and as the name suggests 'query the repository') to do the same for all added repositories, cause rpm is not responsible for that. And actually it does do that using the downloaded repodata (as you already know), but problem is it's no working all the time.
For e.g. it works here --
repoquery -f /etc/htt* htdig-web-4:3.2.0-0.10.b6.el6.x86_64 ipa-server-0:3.0.0-37.el6.x86_64 mod_revocator-0:1.0.3-10.el6.x86_64 php54-apc-panel-0:3.1.15-0.2.svn329724.el6.centos.alt.noarch mod_dav_svn-0:1.6.11-9.el6_4.x86_64 mod_perl-0:2.0.4-10.el6.x86_64 php-0:5.3.3-26.el6.x86_64 mod_authz_ldap-0:0.26-16.el6.x86_64 mod_dnssd-0:0.6-2.el6.x86_64 mod_auth_pgsql-0:2.0.3-10.1.el6.x86_64 php54-php-0:5.4.16-7.el6.centos.alt.x86_64 php54-php-0:5.4.16-7.el6.centos.alt.1.x86_64 httpd-0:2.2.15-29.el6.centos.x86_64 webalizer-0:2.21_02-3.3.el6.x86_64 mod_wsgi-0:3.2-3.el6.x86_64 php54-php-0:5.4.16-16.el6.centos.alt.x86_64 mrtg-0:2.16.2-7.el6.x86_64 gitweb-0:1.7.1-3.el6_4.1.noarch mod_auth_kerb-0:5.4-10.el6.x86_64 httpd-manual-0:2.2.15-29.el6.centos.noarch php54-apc-panel-0:3.1.15-0.4.20130912.el6.centos.alt.noarch squid-7:3.1.10-19.el6_4.x86_64 mod_nss-0:1.0.8-18.el6.x86_64 mod_auth_mysql-1:3.0.0-11.el6_0.1.x86_64 mod_ssl-1:2.2.15-29.el6.centos.x86_64 mailman-3:2.1.12-18.el6.x86_64
On 09/15/2014 11:46 PM, dE wrote:
Hi.
I've found inconstancy between output of repoquery and rpm. I was looking forward towards apache php 5.4 module which must provided by some package SCL (can someone tell me?).
Software collections are provided in a different directory. querying for /etc/whatever or /usr/whatever won't work, as scls live under /opt/rh
For 6, the package is httpd24.x86_64, php54-php.x86_64 etc are the scl packages. To use them, you'd need to install the centos-release-SCL.x86_64 which enables the repositories.
On 09/16/14 21:38, Jim Perrin wrote:
On 09/15/2014 11:46 PM, dE wrote:
Hi.
I've found inconstancy between output of repoquery and rpm. I was looking forward towards apache php 5.4 module which must provided by some package SCL (can someone tell me?).
Software collections are provided in a different directory. querying for /etc/whatever or /usr/whatever won't work, as scls live under /opt/rh
For 6, the package is httpd24.x86_64, php54-php.x86_64 etc are the scl packages. To use them, you'd need to install the centos-release-SCL.x86_64 which enables the repositories.
Yes, thanks for the info, I really didn't know that. It got installed as a symlink in /etc/httpd/modules
However repoquery should list non-SCL packages at least.
-
dE -
Jim Perrin -
Jonathan Billings -
Valeri Galtsev