Bug 758854
Summary: | yum -C issues when run as non-root | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Matt Reid <mreid> |
Component: | yum | Assignee: | Fedora Packaging Toolset Team <packaging-team> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | 16 | CC: | duffy, ffesti, james.antill, maxamillion, plpennell, pmatilai, sheltren, tim.lauridsen, ville.skytta, zpavlas |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-02-13 20:47:31 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Matt Reid
2011-11-30 20:26:02 UTC
I cannot reproduce, it works just fine for me. Note that yum install completions do not include packages that you already have installed, maybe that's why? For "sudo yum install optip" to complete to optipng.$arch, this plain yum command (no completion involved) should list it: yum -d 0 -C list available "optip*" If it is listed but still not completed, do a "set -x" in a shell, invoke the completion that does not work, capture the output and attach it here. The FESCO ticket is somewhat confusing, I'll post some notes to it. $yum -d 0 -C list available "optip*" results in - [Errno 13] Permission denied: '/var/cache/yum/x86_64/16/fedora/8e5f7c264cbd50659a18cd4f87fe75ea728fdc187d4e5e041898070c9dccf5e8-comps-f16.xml' $sudo yum -d 0 -C list available "optip*" results in - Error: No matching Packages to list $yum -d 0 -C list available "gcc*" results in the same permission denied message. $sudo yum -d 0 -C list available "gcc*" results in - Available Packages gcc-gfortran.i686 4.6.2-1.fc16 fedora gcc-gfortran.x86_64 4.6.2-1.fc16 fedora gcc-gnat.x86_64 4.6.2-1.fc16 fedora gcc-go.x86_64 4.6.2-1.fc16 fedora gcc-java.x86_64 4.6.2-1.fc16 fedora gcc-objc.x86_64 4.6.2-1.fc16 fedora gcc-objc++.x86_64 4.6.2-1.fc16 fedora gcc-plugin-devel.i686 4.6.2-1.fc16 fedora gcc-plugin-devel.x86_64 4.6.2-1.fc16 fedora gcc-python-plugin-docs.x86_64 0.6-4.2.fc16 fedora gcc-python2-debug-plugin.x86_64 0.6-4.2.fc16 fedora gcc-python2-plugin.x86_64 0.6-4.2.fc16 fedora gcc-python3-debug-plugin.x86_64 0.6-4.2.fc16 fedora gcc-python3-plugin.x86_64 0.6-4.2.fc16 fedora gccxml.x86_64 0.9.0-0.6.20110211.fc16 fedora Should I have to change the permissions of my yum cache? Seems like that's what I need to do. Optipng was just an example, I haven't gotten yum to autocomplete anything while using sudo, while it autocompletes just fine if I su first. If I put in "complete -cf sudo" in a new terminal and then use sudo with yum, it looks like I can autocomplete installed packages, but a double tab will not list possibilities, it just completes to gcc, libreoffice, optipng, etc. Once I close that terminal, I'll have to issue that command again for it to work like that. I guess complete -cf sudo doesn't do what I was hoping it did. I linked the FESCO ticket just to show that bash-completion will be installed by default, that's unrelated to what I'm experiencing here. Hi Ville, I run Fedora 16, I installed bash-completion today and was able to reproduce Matt's results. If I type: sudo yum install optip And hit tab, nothing happens at all. No matter how many times I hit tab. If I type: sudo su - sudo yum install optip And hit tab, I get completion of the package name. I ran 'yum -d 0 -C list available "optip*"' as you instructed and received the same permission error that Matt did. WRT the FESCo ticket, just because bash-completion is in @Base does not mean it gets installed by default. It has to be flagged as mandatory for that to happen, and since it was not installed on my F16 system by default, I am guessing that is not the case at the moment? Thank you so much for the impressively quick response and helping us out with this issue, it is greatly appreciated. Regarding being installed by default or not, I haven't installed F-16 from scratch yet so I cannot verify it, but if being in the base group as '<packagereq type="default">bash-completion</packagereq>' does not result in it being installed by default, I think something (either software or terminology) is broken somewhere. Flagging it as mandatory seems overkill to me -- I don't know why people shouldn't be given the choice to not install it if they so desire. Regarding the rest of this bug, it's a (long standing) problem in yum; there's nothing bash-completion can do about it. I'm not sure how to describe it better than there are still various problems, at least those "permission denied" ones running various yum commands as non-root in some scenarios (completions for "sudo yum ..." are not run as root but the original user), IIRC especially with yum -C -> reassigning to yum. Unfortunate that yum won't let us do this, thanks for your help though! I talked to geppetto a bit about this bug on IRC; here's some more information for those following along: 1) The problem is that the completion uses yum -C … which uses the root cache 2) The yum devs will probably fix it by just changing a bunch of yum stuff so that yum as a user always uses the user dirs. I haven't gotten any workarounds to work yet (besides simply "sudo su -" then running yum with tab complete) One (poor) workaround is to first run some yum commands as the non-root user without -C to "seed" the user dirs, for example "yum list all", "yum repolist", "yum grouplist" etc, then try the completions. I can add to this, Using Fedora 16, Gnome Terminal or Guake I get issues using tab for auto-completion on many commands including mount. EX1: mount /stor/n[tab]etshare/s[tab]hare/I[tab]SOs //- works fine (but can't mount drive) EX2: sudo mount /stor/n[tab] //- returns no values (have to manually enter info) EX3: sudo mount /s[tab]tor (with a space at the end) //- returns the first directory but no further directories This is mostly a default setup and if I get time I will throw a fresh install on another PC and perform the same tests there. However I think this issue may be more prevalent than just yum. Thanks. Changed summary to reflect the originally reported issue. Please file specific new bugs about new problems so we don't end up with everything lumped here. sudo and mount completion not working properly together is a known issue which will as far as I know be addressed at least to some extent in the upcoming bash-completion 2.0rc1 release which will appear in rawhide soon. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |