[Yum-devel] [PATCH] Much faster "_yum_list available". BZ 919852

Jan Zelený jzeleny at redhat.com
Wed Mar 13 08:33:20 UTC 2013


On 11. 3. 2013 at 10:31:03, Zdenek Pavlas wrote:
> > > On my system, this is about 10-20 times faster (when cached).
> >  
> >  NAK.
> >  Not only that but all configuration (like what repos. are enabled,
> > 
> > excludes/versionlock etc.) are ignored,
> 
> Wouldn't consider that strictly a con..  fixes cases as:
> # yum --enablerepo=* --disableexcludes=* install foo<tab><tab>

Personally, I don't even think it's that important. I prefer having completion 
results ASAP, I don't need them to be 100% accurate. That's why we have 
completion IMO - speed, not accuracy.

Of course there might be some issues that would ultimately block this approach 
but those that have been mentioned are not up there.

> > as is arch information.
> 
> This could be implemented, but I don't think it's necessary.
> Have primary_db.sqlite with packages for $arch? => offer it.

Agreed, more choices are always better

> > It also assumes what the cachedir is.
> 
> $(find /var/cache/yum -name primary_db.sqlite)
> ..should be a safer bet, indeed.
> 
> Having to wait 2s to tab-complete a package name (on a decent
> hardware!) is a major drawback.  Personally, I'd rather use
> this "hack".

Couldn't agree more. Yum autocompletion sucks big time. I always end up doing 
^C and re-typing the entire command again, including the package name, as it 
is (sadly) much faster that way.

All that being said, I acknowledge that there are users who might have a 
different view. Is there perhaps a way how user would switch from one approach 
to the other - for example some env. variable? That way we can provide both, 
leave default as it is now, document it somewhere and ask Fedora users what 
would they prefer as default.

Thanks
Jan


More information about the Yum-devel mailing list