Bug 508004
| Summary: | yum behaviour different for an unprivileged user and 'root' for check-update | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Amit Shah <amit.shah> |
| Component: | yum | Assignee: | Seth Vidal <skvidal> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 11 | CC: | amit.shah, ffesti, james.antill, pmatilai, tim.lauridsen |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-06-25 15:31:54 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
Amit Shah
2009-06-25 05:27:23 UTC
The unprivileged user cannot write to that path, so,no they don't store that info there. The user downloaded metadata is stored in /var/tmp/yum-* This looks like a mirrors-out-of-sync issue to me. Is there more of a bug here? Can you try running makecache a couple more times, to see if it fixes itself? Running a 'yum update' now (which is several hours later after I encountered the bug above) got me the updates which were shown above, so looks like maybe all the mirrors weren't in sync at that time so this was a transient thing. However, this is a really annoying thing to have yum to download metadata as an unprivileged user just for 'yum search' or 'info' operations only to have that downloaded data discarded the next time yum is run as root. Can that be fixed please? I don't want to wait for the downloads to happen before I get the search results. We cannot trust the metadata downloaded by an unprivileged user. I completely agree. What I was suggesting was to stop yum from downloading the metadata when run unprivileged. this behavior was implemented b/c of: https://bugzilla.redhat.com/show_bug.cgi?id=460782 feel free to argue with them. Hm, interesting RFE. Anyway can that behaviour be limited to only when no cache is available to work from with? I'm not inclined to do that. The other RFE made sense, it is why it was implemented. The requester wanted yum to do something reasonable when run as a user. It also makes sense when you realize there are many many many tools which use yum and which run only as a user, not as root. Why is the behavior you desire so important? There are also two properties that you might find useful: 1. If you download the data as root, first ... then the unprivilaged user will use it. 2. If you pass --cache to yum it'll use the cached root data. Replying to Seth's comment: Very simply, I don't want to wait for metadata updates when I want to search for packages or get info on them. James: Option 1 isn't practical each time Option 2 should be default IMO. One will realise that yum will fetch something only after he sees it fetching it. (esp. for someone like me, coming to yum after a really long time spent with apt) then that is the source of your problem. Your thought processes have been broken and damaged by apt. We have a rehabilitation centers you can check yourself into to help with this problem. With unlimited electro-shock therapy you can get rid of bizarre apt-isms. :-D Well, anything that will not require me to wait 1 min or 2 or 5 before I get results for my simple yum queries.. Where are you waiting that long for simple queries? Yum holds the cache for quite a while. So that brings us back to the original thing: when I filed this BR, updates/primary_db took 54 seconds to download. Maybe I was lucky that it took "only" 54s, but I see it as an unacceptable delay for a simple 'yum search'. |