Bug 502697 - command not found feature is very slow and unusable
Summary: command not found feature is very slow and unusable
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-packagekit
Version: 11
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-05-27 00:41 UTC by Rahul Sundaram
Modified: 2013-03-13 05:45 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-23 10:33:46 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Rahul Sundaram 2009-05-27 00:41:01 UTC
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-27 01:39:38 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]

Comment 2 Rahul Sundaram 2009-05-27 01:55:49 UTC
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 07:18:30 UTC
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 07:25:55 UTC
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 16:37:01 UTC
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 20:58:28 UTC
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 15:13:49 UTC
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 16:09:30 UTC
(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 20:20:00 UTC
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 10:33:46 UTC
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 09:06:03 UTC
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.