Bug 502697
Summary: | command not found feature is very slow and unusable | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Rahul Sundaram <sundaram> |
Component: | gnome-packagekit | Assignee: | Richard Hughes <richard> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 11 | CC: | carenas, hedayatv, mclasen, rhughes, richard, smohan, tristanmoody, valent.turkovic |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-03-23 10:33:46 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
Rahul Sundaram
2009-05-27 00:41:01 UTC
It is unusably slow, since it insists on downloading file lists. But if you wait long enough, it'll eventually say: Command not found. Install package 'lxsplit' to provide command 'lxsplit'? [N/y] I checked again and you are right and this is a enormous delay. I am updating the title. The issue is when we ask yum to search by file it downloads the file lists, so the search results are valid. I see we have two possible solutions: * Request yum work from it's cache, and abandon the request if there are no previous file lists (should take about 100ms to service) * Provide feeback on the command line that we are downloading file lists. Note, once you have the file lists, the next request is very fast. Richard. yes, if I run yum makecache and do this, it works fine but the first experience is going to be painfully bad. For the first time atleast, you should be providing some progress. Subsequent runs can merely run off cache I think. Ubuntu has something similar. Have you looked at how it is being handled? This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Yes, IMHO PackageKit-command-not-found should not try to download ANYTHING by default since it'll bring a very negative experience for the user. This is specially more important since it is going to be enabled by default in Fedora 12. I think it should try to download needed files if the user explicitly wants that. Just consider that you typed a command incorrectly (e.g. cdc instead of cd) and you see that this plugin locks your terminal, trying to download file lists. It'll make working in bash painful, since you'll probably try to use Ctrl+C and it doesn't respond immediately. This plugin in it's current form slows down working in bash, except for users with high speed internet connection. I used this plug-in for awhile in F11, but then decided to remove it since I find it just "in the way". I've also found that it screws up the root login terminal. For some reason, something in the login sequence is activating this. As a result "Command not found." gets passed to alias and export, which causes further errors in the login process. I had no choice but to remove the package to make the root login terminal usable. (In reply to comment #7) > I had no choice but to remove the package to make the root > login terminal usable. I think you need to fix the problem, not workaround it. Richard. Without this package however, no "command not found" errors are present, so I have no idea what is tripping it. It's a default installation, so I assume there wouldn't be any silly errors like that right off the DVD, right? With PackageKit in F13, we hint to the backend that we want fast results, not 100% correct results, and hence CNF is much quicker. I have seen this feature also in ubuntu, and it's blazing fast, instant reply. They probably keep an offline list of most common commands in one text file. I'll test how this works on F13 and give you comparison in next reply. |