Bug 508004 - yum behaviour different for an unprivileged user and 'root' for check-update
yum behaviour different for an unprivileged user and 'root' for check-update
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-06-25 01:27 EDT by Amit Shah
Modified: 2014-01-21 18:10 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-25 11:31:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Amit Shah 2009-06-25 01:27:23 EDT
Description of problem:
When I did a 'yum search' as an unprivileged user, yum fetched the updates as well:

$ yum search linphone
Loaded plugins: presto, refresh-packagekit                                       
rpmfusion-free-updates                                                 | 3.8 kB     00:00     
rpmfusion-free-updates/primary_db                                      |  95 kB     00:01
updates/metalink                                                       | 3.2 kB     00:00     
updates                                                                | 4.4 kB     00:00     
updates/primary_db                                                     | 2.0 MB     00:54     
===================================== Matched: linphone ======================================


yum check-update shows me there are pending updates:

$ yum check-update 
Loaded plugins: presto, refresh-packagekit                                     

PyKDE4.x86_64                              4.2.4-2.fc11                 updates               
apr.x86_64                                 1.3.5-1.fc11                 updates               
apr-util.x86_64                            1.3.7-1.fc11                 updates               
audit.x86_64                               1.7.13-1.fc11                updates               


However, when I did a 'yum update' as root, it only updated the gstreamer-ffmpeg package from the rpmfusion repos.

I did a 'yum makecache' after that but again didn't get any updates. I'm guessing the mirror might have changed between the two yum invocations but doesn't the yum metadata downloaded when an unprivileged user invokes yum get stored in the /var/log yum cache?

(This is an F11 system)
Comment 1 seth vidal 2009-06-25 10:31:20 EDT
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?
Comment 2 James Antill 2009-06-25 10:58:02 EDT
Can you try running makecache a couple more times, to see if it fixes itself?
Comment 3 Amit Shah 2009-06-25 11:29:26 EDT
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.
Comment 4 seth vidal 2009-06-25 11:31:54 EDT
We cannot trust the metadata downloaded by an unprivileged user.
Comment 5 Amit Shah 2009-06-25 11:38:29 EDT
I completely agree. What I was suggesting was to stop yum from downloading the metadata when run unprivileged.
Comment 6 seth vidal 2009-06-25 11:59:52 EDT
this behavior was implemented b/c of: https://bugzilla.redhat.com/show_bug.cgi?id=460782

feel free to argue with them.
Comment 7 Amit Shah 2009-06-25 12:10:41 EDT
Hm, interesting RFE. Anyway can that behaviour be limited to only when no cache is available to work from with?
Comment 8 seth vidal 2009-06-25 12:20:45 EDT
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?
Comment 9 James Antill 2009-06-25 12:27:45 EDT
 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.
Comment 10 Amit Shah 2009-06-25 12:32:17 EDT
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.

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)
Comment 11 seth vidal 2009-06-25 12:42:11 EDT
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.

Comment 12 Amit Shah 2009-06-25 13:11:44 EDT
Well, anything that will not require me to wait 1 min or 2 or 5 before I get results for my simple yum queries..
Comment 13 seth vidal 2009-06-25 13:29:50 EDT
Where are you waiting that long for simple queries? Yum holds the cache for quite a while.
Comment 14 Amit Shah 2009-06-25 13:37:08 EDT
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'.

Note You need to log in before you can comment on or make changes to this bug.