Michael Schwendt mschwendt@gmail.com wrote:
"dnf --refresh" is more like "dnf clean expire-cache", which sometimes gives additional updates to plain "dnf upgrade", but there still seems some caching involved that keeps it from providing all updates available.
Doubtful.
"dnf update --refresh" here (Rawhide) always redownloads the metadata. That's behaviour like running after "dnf clean metadata", not "dnf clean expire-cache". [1]
Neither "dnf --refresh upgrade" nor "dnf clean expire-cache;dnf upgrade" will try to download the base Fedora data (F22). Only "dnf clean metadata" plus "dnf upgrade" force a full refresh.
Just try it out. "--refresh" and "clean expire-cache" result in the same. That also matches the documentation. Both set the metadata some kind of expired but don't really remove the data.
"dnf clean metadata" actually removes all metadata and therefore forces a reload for all repositories. It's more like brute force. :-)
Also according the the DNF documentation (FAQ), "dnf clean metadata" is the recommended way to get latest updates. That matches my experience.
Greetings, Andreas
On Sun, 16 Aug 2015 11:51:47 +0000 (UTC), Andreas M. Kirchwitz wrote:
"dnf --refresh" is more like "dnf clean expire-cache", which sometimes gives additional updates to plain "dnf upgrade", but there still seems some caching involved that keeps it from providing all updates available.
Doubtful.
"dnf update --refresh" here (Rawhide) always redownloads the metadata. That's behaviour like running after "dnf clean metadata", not "dnf clean expire-cache". [1]
Neither "dnf --refresh upgrade" nor "dnf clean expire-cache;dnf upgrade" will try to download the base Fedora data (F22). Only "dnf clean metadata" plus "dnf upgrade" force a full refresh.
Rawhide. I refer to Rawhide! I cannot afford spending time on this issue with F22 in addition to Rawhide.
"dnf --refresh update" here **always** redownloads the metadata.
Just try it out. "--refresh" and "clean expire-cache" result in the same. That also matches the documentation. Both set the metadata some kind of expired but don't really remove the data.
Once more: doubtful. Whether "--refresh" doesn't remove the metadata is not of interest, since it redownloads it afterwards anyway.
And whether it "matches the documentation" remains to be seen. I haven't examined the implementation. Does --refresh really do anything to confirm the checksum of the metadata cache before deciding to redownload? Then why does it redownload always here?
----- Original Message -----
From: "Michael Schwendt" mschwendt@gmail.com To: users@lists.fedoraproject.org Sent: Sunday, August 16, 2015 2:01:27 PM Subject: Re: More dnf annoyance
On Sun, 16 Aug 2015 11:51:47 +0000 (UTC), Andreas M. Kirchwitz wrote:
"dnf --refresh" is more like "dnf clean expire-cache", which sometimes gives additional updates to plain "dnf upgrade", but there still seems some caching involved that keeps it from providing all updates available.
Doubtful.
"dnf update --refresh" here (Rawhide) always redownloads the metadata. That's behaviour like running after "dnf clean metadata", not "dnf clean expire-cache". [1]
Neither "dnf --refresh upgrade" nor "dnf clean expire-cache;dnf upgrade" will try to download the base Fedora data (F22). Only "dnf clean metadata" plus "dnf upgrade" force a full refresh.
Rawhide. I refer to Rawhide! I cannot afford spending time on this issue with F22 in addition to Rawhide.
"dnf --refresh update" here **always** redownloads the metadata.
Just try it out. "--refresh" and "clean expire-cache" result in the same. That also matches the documentation. Both set the metadata some kind of expired but don't really remove the data.
Once more: doubtful. Whether "--refresh" doesn't remove the metadata is not of interest, since it redownloads it afterwards anyway.
And whether it "matches the documentation" remains to be seen. I haven't examined the implementation. Does --refresh really do anything to confirm the checksum of the metadata cache before deciding to redownload? Then why does it redownload always here?
It's a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1226724 :-(