Bug 1064226 - [rfe] cmdline option forcing cache refresh
[rfe] cmdline option forcing cache refresh
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
rawhide
Unspecified Unspecified
low Severity unspecified
: ---
: ---
Assigned To: Honza Silhan
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-02-12 04:24 EST by Hans de Goede
Modified: 2014-05-31 19:58 EDT (History)
5 users (show)

See Also:
Fixed In Version: dnf-plugins-core-0.0.8-2.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-05-31 19:58:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2014-02-12 04:24:15 EST
Hi,

I'm not exactly sure what the cache-refresh timeout is, but today I hit a situation where I knew newer stuff was available then dnf was seeing.

I ended up having todo a:
dnf clean all
dnf update

To get dnf to see the newer repo metadata, it would be nice to be able todo:

dnf --metadata-refresh update

Or something similar, a better cmdline option name certainly is welcome :)

Also I believe that "dnf makecache" should always go out to the network and see if there is newer metadata, when the user explictly runs "dnf makecache" he very likely wants to get the latest version.

Regards,

Hans
Comment 1 Ales Kozumplik 2014-02-12 11:13:18 EST
Hi, this is several points made here and most of them have been refuted in older bugs:

> I'm not exactly sure what the cache-refresh timeout is

48 hours by default unless specified in the .repo file. If there are repos your development depends on then perhaps set their expire time to 0 to always be sure to be getting fresh MD.

> situation where I knew newer stuff was available then dnf was seeing.

Try to understand: knowing the release of updates etc. is typical of power users and we want to save the remaining majority of users from having to wait to MD sync too often.

> I ended up having todo a:
> dnf clean all
> dnf update

correct thing to do in this use case.

> To get dnf to see the newer repo metadata, it would be nice to be able todo:
> 
> dnf --metadata-refresh update

We will consider doing this. I have been averse of it for some time because it only does what can already be done by clean && update so it is a bit of a bloat.

> Also I believe that "dnf makecache" should always go out to the network and
> see if there is newer metadata, when the user explictly runs "dnf makecache"
> he very likely wants to get the latest version.

'dnf makecache', as described by the manual, has the semantics of bringing the cache to a fresh state. If it doesn't have to download anything because everything's fresh then even better. Again---dnf clean metadata && dnf makecache is for that. We try to avoid bloat and have things orthogonal.
Comment 2 Hans de Goede 2014-02-12 11:25:38 EST
Hi,
(In reply to Ales Kozumplik from comment #1)
> Hi, this is several points made here and most of them have been refuted in
> older bugs:
> 
> > I'm not exactly sure what the cache-refresh timeout is
> 
> 48 hours by default unless specified in the .repo file. If there are repos
> your development depends on then perhaps set their expire time to 0 to
> always be sure to be getting fresh MD.

What would the syntax for that be, I just tried adding:
metadata_expire=4h
But that does not seem to work.

Does dnf have a new tag for this ? It would be nice if it could just re-use the metadata_expire
config directive, even though it will have a different default

> > situation where I knew newer stuff was available then dnf was seeing.
> 
> Try to understand: knowing the release of updates etc. is typical of power
> users and we want to save the remaining majority of users from having to
> wait to MD sync too often.

Right, I'm not arguing against that, just asking for an easy way to override this behavior.

> 
> > I ended up having todo a:
> > dnf clean all
> > dnf update
> 
> correct thing to do in this use case.

I've just learned using "dnf clean expire-cache" would have been even more correct.
> 
> > To get dnf to see the newer repo metadata, it would be nice to be able todo:
> > 
> > dnf --metadata-refresh update
> 
> We will consider doing this. I have been averse of it for some time because
> it only does what can already be done by clean && update so it is a bit of a
> bloat.

I think that being able to do:

dnf --expire-cache update

and also:

dnf --expire-cache makecache

Makes a ton of sense to have.
Comment 3 Ales Kozumplik 2014-02-12 11:48:00 EST
(In reply to Hans de Goede from comment #2)
> What would the syntax for that be, I just tried adding:
> metadata_expire=4h
> But that does not seem to work.

That's the right syntax.
Comment 4 Tim Lauridsen 2014-04-02 08:12:42 EDT
Just a comment

dnf clean expire-catch && dnf update

show expire the cache and dnf will check if the metadata is updated, but you don't havde to rebuild everything that take long time.
Comment 5 Tim Lauridsen 2014-04-02 08:13:37 EDT
it should have been : dnf clean expire-cache
Comment 6 Honza Silhan 2014-04-16 06:41:08 EDT
Added new switch '--refresh' that will mark all repos as expired before running a command. Basicaly it's "dnf clean expire-cache && dnf COMMAND" alternative.
Comment 7 Fedora Update System 2014-05-02 04:32:17 EDT
dnf-0.5.1-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/dnf-0.5.1-1.fc20
Comment 8 Fedora Update System 2014-05-02 17:04:50 EDT
Package dnf-0.5.1-1.fc20, hawkey-0.4.14-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dnf-0.5.1-1.fc20 hawkey-0.4.14-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-5937/hawkey-0.4.14-1.fc20,dnf-0.5.1-1.fc20
then log in and leave karma (feedback).
Comment 9 Fedora Update System 2014-05-28 08:10:07 EDT
dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libsolv-0.6.1-1.git6d968f1.fc20,hawkey-0.4.16-1.fc20,dnf-0.5.2-1.fc20,dnf-plugins-core-0.0.8-2.fc20
Comment 10 Fedora Update System 2014-05-28 19:50:06 EDT
Package dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dnf-plugins-core-0.0.8-2.fc20 libsolv-0.6.1-1.git6d968f1.fc20 hawkey-0.4.16-1.fc20 dnf-0.5.2-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-6789/libsolv-0.6.1-1.git6d968f1.fc20,hawkey-0.4.16-1.fc20,dnf-0.5.2-1.fc20,dnf-plugins-core-0.0.8-2.fc20
then log in and leave karma (feedback).
Comment 11 Fedora Update System 2014-05-31 19:58:40 EDT
dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

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