[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