Bug 1279282

+
3. when DNF consider them as expired (see metadata_expired [1] configuration option in /etc/dnf/dnf.conf).

You can set it to higher value or completely disable (-1)

[1] http://dnf.readthedocs.org/en/latest/conf_ref.html

What? No, I don't want to disable automatic refreshing of the cached metadata. My point is that it's silly for commands like repoquery to trigger a refresh of all repositories, since dnf by default is already configured to look for updates in the background.

Perhaps we should look at it from another perspective: If a user wants to *manually* update the metadata, there are commands (makecache) and command switches (--refresh) to do so. However, if a user *does not* want to trigger extra refreshes, they have no options, and they will be forced to wait for repo information to download again when running certain dnf commands.

Perhaps there is a better solution than the one I suggested, but I don't believe changing the time expire the metadata is it. So, I'm sorry, but I don't think Jan's response really addresses the problem.

Automatic background checks for updated metadata is already fine and good. Triggering *another* refresh for simple commands (such as a --what-provides for something already installed) forces the user to wait for what should be a very simple query. It's bad User Experience.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

I would like ask you about user that you use to run command ``dnf repoquery``. If you run it with root or sudo it use root's metadata cache, but if you run it like other user, you will see, that dnf download another cache. Same is applied for dnf clen command. You delete different cache if you run ``dnf clean all`` and ``sudo dnf clen all``.

I normally only run commands with sudo if it's required, so I run `dnf repoquery` as my regular user.

Maintaining a separate cache for each user seems silly: On a multi-user rig, anyone may be curious about the applications and dependencies installed on the system, but only one user account can install, remove, or upgrade packages.

Just think about cache problem. Just look at following questions. If every user will use only single cache - 
1. Can every user read single copy of cache - yes
2. Can every user modified or overwrite single copy of cache - no, this behavior could be a security problem. But if some user cannot modified cache, therefore they cannot download new metadata even if they are expired, corrupted or unavailable. Therefore some users can be very surprise. Also the present behavior has down-site like more space is required, presence of different versions of metadata can result in different results (commands that do not refresh metadata like with 'dnf list extras'). Also the solution could be to allow use of dnf only with root account, but it is even worse. I think there is not a perfect solution for this case. I can say feel free to help with dnf development, any contribution is welcome.

Anyway the present behavior is not a bug, therefore I am closing the report.

Sorry, Jaroslav, I didn't understand half of what you said. If only root can actually change packages, then what does it matter if other users make simple queries based on slightly out-of-date information? It is the administrator's responsibility to keep the cache and packages up-to-date. For other users, DNF queries merely satisfies their curiosity.

In fact, having only a single copy of the cache would also mean that it should *always* be up-to-date, because the dnf cache updater by default runs on a timer. If there were only one cache, everyone would always have the latest information!

Which brings me back to my point in the original post: Since dnf already regularly updates its cache in the background, triggering a cache update for repo queries and other commands is a waste of time.

I'm starting to feel bad for continually harping on this issue. I'm willing to be wrong here. But you haven't actually addressed the problem I'm talking about.

* DNF by default is set up to update its cache in the background.
* If the local administrator is really concerned, there are ways to force a metadata update, such as the makecache subcommand, or the --refresh flag.
* Therefore, why bother triggering updates *again* for dnf repoquery?

Thank you very much for your report. There are plans to change the behavior even with cooperation with other software management tools to use single copy of metadata, but we cannot promise any time period when it happen.