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
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.
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.
(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.
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.
it should have been : dnf clean expire-cache
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.
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
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).
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
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).
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.