Bug 163465
Summary: | Make yum feel snappier by caching repodata files | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Sigge Kotliar <sigge> |
Component: | yum | Assignee: | Jeremy Katz <katzj> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | katzj |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-09-21 18:06:29 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
Sigge Kotliar
2005-07-17 17:08:25 UTC
I think the recommended implementation would end up with extremely frustrated users. We'd be better off getting the last-changed info from the repository server and compare that to the repomd.xml we have on disk - but even then we'll still need to contact the repository Well, I can agree that it will be a slight frustration, but I think that the current frustration of waiting ~5 seconds every time is worse. Apt (yes, the other packaging system, sorry for bringing it up) needs an apt-get update before you run any command to get the latest data. Although I'm not suggesting the same system, but frustrated users could do a "yum check-update" to get the absolutely latest packs. Also, as the system works now with mirrors, you can quite often get two different versions of the "yum check-update" list if you do it twice. I've had cases with three different versions on different mirrors. So the frustration you talk about is already there. Now we'll at least lessen it. Just getting the last-changed header I think would be an improvement, but an extremely small one. Getting 1kB of data takes virtually no time, even on a modem, it's the connecting part that takes time. Just my 2 cents, but I really believe this is the way to go. The two stage process used by apt is a good way of ensuring that users don't actually get updates (since they don't remember to do the first part or other such things). Getting the repodata every time is really the only way to be assured consistency. Jeremy: with all though respect, I don't think you read my suggestion properly. I'm not suggesting an apt-like two stage process. What I'm suggesting is that if a repodata file has been stored less than say an hour ago that yum doesn't get a new one. No users would miss any updates - cause the synk difference is even bigger between different mirrors than it would be with this one hour storage of repodata files. It would also help tremendously for everyone who is doing consecutive requests, ie doing: yum install app-a; yum install app-b. Why two different connections are needed I don't see. With commands like yum search, yum info and yum remove, not even one is needed, unless the repodata file is terribly out of sync, since the names of the rpm's on the server rarely change - only the versions. Please review this again, I really do believe in this. So we figured out a way to do this w/o going crazy. Refiling this as rawhide - it will hit rawhide in a future yum release. not quite how you wanted it done - but I think it will cover the problem. Just downloaded and tried out yum-2.4.0-9. Is this the version you are talking about? Remove operations are now really speedy. On this point I'm really happy. But for Doing "yum install something; yum install somethingelse" however still pings each repo twice - once per command. Same goes for search. On my system the difference was about 6 secs between "yum search verylongquery" and "yum -C search verylongquery". Of course, with the total time spent being 20 or 26 second this may not seem much, but for modem users, or people with bad connections it would be ever greater. Perhaps this is something that can be further improved with the new plugin architecture? the version if rawhide does not have that patch. oh. ok then =) Will wait for the next rawhide release of yum then, and get back to you then. wait until yum 2.4.1 hits rawhide. |