Bug 502697 - command not found feature is very slow and unusable
command not found feature is very slow and unusable
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gnome-packagekit (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-26 20:41 EDT by Rahul Sundaram
Modified: 2013-03-13 01:45 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-23 06:33:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rahul Sundaram 2009-05-26 20:41:01 EDT
Description of problem:

# rpm -q PackageKit-command-not-found
PackageKit-command-not-found-0.4.6-8.fc11.i586

# lxsplit
Command not found.
Comment 1 Matthias Clasen 2009-05-26 21:39:38 EDT
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]
Comment 2 Rahul Sundaram 2009-05-26 21:55:49 EDT
I checked again and you are right and this is a enormous delay. I am updating the title.
Comment 3 Richard Hughes 2009-05-27 03:18:30 EDT
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.
Comment 4 Rahul Sundaram 2009-05-27 03:25:55 EDT
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?
Comment 5 Bug Zapper 2009-06-09 12:37:01 EDT
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
Comment 6 Hedayat Vatankhah 2009-08-20 16:58:28 EDT
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".
Comment 7 Tristan Moody 2009-09-03 11:13:49 EDT
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.
Comment 8 Richard Hughes 2009-09-03 12:09:30 EDT
(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.
Comment 9 Tristan Moody 2009-09-03 16:20:00 EDT
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?
Comment 10 Richard Hughes 2010-03-23 06:33:46 EDT
With PackageKit in F13, we hint to the backend that we want fast results, not 100% correct results, and hence CNF is much quicker.
Comment 11 Valent Turkovic 2010-07-05 05:06:03 EDT
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.

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