Description of problem: comments from wdc 2. yum whatprovides behavior seems to have changed radically with this new version. 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): yum-3.2.8-9.el5_2.1 seems to be working fine on a 5.1 as per my tests.
This bug is not specific to ooffice. Try yum whatprovides sh Same Error!
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).
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 release.
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 line. 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 /usr/bin/ooffice 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 file. 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 error. ---- 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.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
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.
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.
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.
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?
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>
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.
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-1.5.5.4-1 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?
YMMV, there is a git repo available at: http://www.kernel.org/pub/software/scm/git/RPMS/git.repo HTH, Brock
Well, that SHOULD have worked, but it didnt. But today I learned more mysteries of yum, and got comfy adding MULTIPLE repositories. Having added rpmforge, I was able to do: yum install perl-Error and THEN yum install git worked. 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...
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.
Not to worry, you want to enable the epel repository: http://fedoraproject.org/wiki/EPEL/FAQ#How_can_I_install_the_packages_from_the_EPEL_software_repository.3F ...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.
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!
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.
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.
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.
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.
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. http://rhn.redhat.com/errata/RHBA-2009-0176.html