Bug 448955 - RFE: Fixup yum whatprovides output
RFE: Fixup yum whatprovides output
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: James Antill
Jan Hutař
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2008-05-29 14:12 EDT by Pradeep Kilambi
Modified: 2009-01-20 16:44 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-20 16:44:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Pradeep Kilambi 2008-05-29 14:12:10 EDT
Description of problem:

comments from wdc@mit.edu

2. yum whatprovides behavior seems to have changed radically with this new

Previously "yum whatprovides ooffice" would give a list of packages and the
paths to all files that had "ooffice" in them.  Usefully it would tell me
what packages were responsible for providing /usr/bin/ooffice

Now, instead of a list of paths and packages I get
Error: No matching Packages to list

That seems incorrect!
Is that message a consequence of the remedy for this bug, or have we a new bug?

Version-Release number of selected component (if applicable):

seems to be working fine on a 5.1 as per my tests.
Comment 1 wdc 2008-05-29 15:21:44 EDT
This bug is not specific to ooffice.

Try yum whatprovides sh

Same Error!
Comment 2 James Antill 2008-05-29 16:24:26 EDT
 So in both versions you can do:

 yum provides '*bin/ooffice'

...yes, it used to also match directly against all file basenames (although this
wasn't documented) but that was fixed/removed.
 If you want to open this as a feature request then I'd recommend opening it
against Fedora 9's yum (if it goes into Fedora 9's version backporting it for
RHEL-5.y will likely be done).
Comment 3 RHEL Product and Program Management 2008-06-02 15:56:21 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 4 wdc 2008-06-02 16:41:15 EDT
Well neither the previous behavior nor the current behavior are ideal.

The previous behavior would spew page after page of matches, telling all and sundry packages for all 
and sundry matches to anything that contained as a substring the argument provided on the command 

The current behavior changed with no mention of a change, and I guess "you just have to know as part 
of the yum oral tradition" that the way you use the whatprovides command is different, and how to get 
something useful.

The current output provides only the package name and its description. It does not provide the actual 
path matched.

The current output also provides that single line of output multiple times, for reasons that are unclear.
Perhaps there are multiple matches.

Ideally the output from, "yum whatprovides /usr/bin/ooffice" would be a single 2 line output:

        openoffice.org-core-x86_64: core modules for openoffice.org

instead of:

        openoffice.org-core-x86_64: core modules for openoffice.org

repeated SEVEN times.

At the very least the man page needs refinement beyond:

       provides or whatprovides
              Is used to find out which package provides some feature or file.
              Just use a specific name or a file-glob-syntax wildcards to list
              the packages available or installed that provide that feature or

That documentation leaves out details that would lead one to think that for an installed and working
/usr/bin/ooffice that a "no matching files" output from "yum whatprovides ooffice" is caused by an 


I would like to participate usefully in the evaluation of the enhancement.  How can I learn what SPECIFIC 
change is being evaluated for inclusion in a maintenance release?

Thanks in advance,
Hope I can help.
Comment 5 RHEL Product and Program Management 2008-06-02 17:23:54 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 
Comment 6 James Antill 2008-06-02 18:24:29 EDT
The current behavior changed with no mention of a change, and I guess "you just
have to know as part  of the yum oral tradition" that the way you use the
whatprovides command is different, and how to get  something useful.

...that's not a fair assessment.
 What happened is that:

 1) matching basenames was undocumented and bad behaviour, so that was fixed.
 2) output uses the same code path as search output ... and so changed when we
fixed the search output to be better.

...you can get the "large" search/provides output by using the -v (verbose)
option, for upstream-3.2.x/5.3 I've also put provides into the showduplicates
output mode (the reason you are getting the same package X times is that you
have X versions of that package).
 If you want to re-open just for the output fixes, feel free.
Comment 7 wdc 2008-06-06 10:28:54 EDT
Thank you for helping me understand the rationale behind the change, and behind the need not to 
change the documentation.

As the MIT Linux platform coordinator, responsible for shepherding users across changes, I need to 
warn you that, even though conceptually what the developers did was 100% correct: Changing the 
defective code so that it more accurately implemented the documented behavior, my users will be 
disoriented by the change of behavior that came without warning.  In fact, a level 2 Red Hat engineer 
working on the Red Hat Satellite server and I have been using that command as a test for debugging a 
race condition in the Satellite Server.  We were both completely blindsided by how our basic test case 
suddenly began behaving differently.  But I digress.

Yes, indeed I would like to re-open this bug. Let's do what we can to make the default output as useful 
as possible.

I would characterize the desired change as:

Change the actual behavior:

yum whatprovides /usr/bin/ooffice

yields the same line:
openoffice.org-core.x86_64 : core modules for openoffice.org
seven times, and an 8th time with "core" capitalized.

to the desired behavior:

In addition to the package description, the output should provide the package name, and the string 
that was matched.  So that output would look more like:

Package: openoffice.org-core - 1:2.0.4-5.4.26.x86_64
Description: openoffice.org-core.x86_64 : core modules for openoffice.org
Match: /usr/bin/ooffice

Package: openoffice.org-core - 1:2.0.4-5.4.25.x86_64
Description: openoffice.org-core.x86_64 : core modules for openoffice.org
Match: /usr/bin/ooffice


I don't have permission to re-open this ticket.  Is re-opening this one appropriate, or starting a fresh 
ticket most appropriate.

Thank you again for the help.

Comment 8 James Antill 2008-06-06 11:54:15 EDT
 Ok, if you could test the upstream commit
b23f24ba5e64020d228f2fda7ac858f2ad7c5985 (the yum-3_2_X branch) and tell me what
you think, that'd be great.
 I'm 99% sure that will make you happy though, and remove any confusion people have.
Comment 9 wdc 2008-06-06 11:59:26 EDT
I would be delighted to test the upstream commit!

Forgive my being ignorant.  What is the quickest way for me to obtain that?
Regrettably, I do not know where the yum development universe is.
Do I need to learn how to build yum from source in order to perform this test?

Comment 10 James Antill 2008-06-06 12:09:21 EDT
 From 3.2.8 it should be as simple as:

% git clone http://linux.duke.edu/yum/git/yum.git
% cd yum; ./yummain.py <cmds>
Comment 11 James Antill 2008-06-06 12:11:58 EDT
 Except I'm forgetting that you'll need to change to the branch, so run:

git co -b yum-3.2.x origin/yum-3_2_X

...after the cd.
Comment 12 wdc 2008-06-09 13:48:59 EDT
Sorry for the delay in following up, I had to clear out some work tasks before resuming work here.

I am running a stock RHEL 5 environment, and do not have git installed, nor do I know the most
efficient way to do so.  I've been to kernel.org/pub/software/scm/git/RPMS/x86_64.
I fetched git-all- and then all the other pieces in that subdirectory that RPM complained 
about as failed dependencies.

Alas, It still wants "tla" "cvsps" which I've never heard of, and have no clue where to find, as
well as a raft of perl subversion libraries that I also have not the faintest clue where to find.

One of the things I like most about Red Hat is that someone has actually chased down all the 
dependencies that "your're just supposed to know", and crafted actual working packages with all the 
pieces either brought along or part of the system.

Is there such a package for RHEL5? Will I find it in EPEL?
Comment 14 Brock Organ 2008-06-17 14:43:45 EDT
YMMV, there is a git repo available at:



Comment 15 wdc 2008-06-17 19:16:44 EDT
Well, that SHOULD have worked, but it didnt.
But today I learned more mysteries of yum, and got comfy adding MULTIPLE

Having added rpmforge, I was able to do:
    yum install perl-Error
and THEN
    yum install git

I guess you're "Just supposed to know"...

Now let's log out of the root account and see if I can build the yum branch...
Comment 16 wdc 2008-06-17 19:30:46 EDT
And we're off and stopping, I'm afraid.
I got that "git co" was a typo, and presume it was supposed to be "git checkout".

But it looks like your build environment has modules/libraries that I do not have:

[wdc@wdc-rhel5-test yum]$ ./yummain.py whatprovides /usr/bin/ooffice
Traceback (most recent call last):
  File "./yummain.py", line 27, in ?
    from yum import Errors
  File "/home/wdc/yum/yum/__init__.py", line 43, in ?
    import rpmsack
  File "/home/wdc/yum/yum/rpmsack.py", line 22, in ?
    import misc
  File "/home/wdc/yum/yum/misc.py", line 19, in ?
    import gpgme
ImportError: No module named gpgme

How do I get past these errors?
Sorry to be uninformed about this. I've never used git before, and I've never
built yum before.
Comment 17 James Antill 2008-06-17 22:58:09 EDT
 Not to worry, you want to enable the epel repository:


...and then do "yum install pygpgme" (git is in there too, and doesn't have the
problem you described above ... but if it works already don't change it).
 Also make sure that after the git clone you did: "git checkout
origin/yum-3_2_X" which will move you to the stable 3.2.x branch.

 At that point it _should_ work.

 If you're still having problems then feel free to leave it, when I'm back next
week I'll make a yum repo. with all the bits in it.
Comment 18 wdc 2008-06-18 00:05:15 EDT
Thanks VERY much!  That got everything in place, and enabled me to see the output.
I got the bonus of losing my fear of hooking in alternate repositories, as well as my first experience
with EPEL which I've been meaning to try out for some time.

I VERY MUCH like how I get a clear explanation:
Warning: 3.0.x versions of yum would erronously match against filenames.
 You can use "*/ooffice" and/or "*bin/ooffice" to get that behaviour
No Matches found

That is precisely the kind of helpful diagnostic I was hoping for.

I also very much like the detailed output:

1:openoffice.org-core-2.3.0-6.5.el5.i386 : Core modules for openoffice.org
Matched from:
Filename    : /usr/bin/ooffice

I have two questions:

1. What is the "Matched from:" line trying to tell me?  Is "Filename:" one of many things that can be 
matched from?  The line wrap confuses me.

2. In chatting with friends about my desires for yum output, I was warned that yum output needs to be 
able to be parsed by scripts.  Were you able to make this output this rich within the confines of a 
reasonable grammar that scripts will be able to parse?  I'm concerned that you've done very well at the 
area that I feel strongly about, but I hope not at the expense of other functionality.

See you at the Summit tomorrow!
Comment 19 wdc 2008-06-18 00:11:49 EDT
OOOH!  I just ran one more test case:  Running yum as non-root.
There is new behavior that I like:

Running as non-root means I can't get access to the RHN remote repositories, but I DO get output 
based on what is locally installed.  I really like that because, the thing I am trying to do when I run yum 
whatprovides is to remember the exact name and version number of the RPM that is installed that 
provides that file.  The new output does that very well.

However, I still feel the diagnostic, "RHN support will be disabled." will be mis-interpreted by many 
that they have broken RHN support.  The diagnostic, "RHN support is enabled only when yum is run as 
root" seems to me much clearer.

I don't know where that diagnostic comes from inside the bowels of yum and RHN, so I don't know how 
sensible such a change would look in other contexts, but I'd be grateful if a refinement along the lines I 
suggest could be considered.

Comment 20 wdc 2008-07-21 17:48:24 EDT
I realize that this is a minor bug, but maybe we can spend a total of half an hour on it together and get 
it out of our lives once and for all.

I presume that the RHN-related stuff is NOT part of upstream yum.  I'd like to get the subtle wording 
change to either completely delete the additional output sentence, "RHN support will be disabled.", or
to change it to "RHN support is enabled only when yum is run as root"

And I'd like to have a clear sense that that change is in the pipe for incorporation in a later version of 
RHEL 5.  (If that text *IS* part of upstream yum, then getting it committed upstream is 100% sufficient 
to me to closing this bug.
Comment 21 James Antill 2008-07-21 22:21:08 EDT
 Right, that msg comes from yum-rhn-plugin ... so you'd need to log a bug there,
but I'd also prefer to fix it by providing access to the downloaded SQL
databases when run as non-root.
Comment 22 wdc 2008-08-06 18:39:39 EDT
I went to open the aforementioned bug in yum-rhn-plugin, and see that bugzilla 456540 has been opened.  Let's call this bug resolved, and use that bug as the way forward on the remaining issue raised here.
Comment 27 errata-xmlrpc 2009-01-20 16:44:43 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.