DNF: why does it refresh metadata all the time

Zdenek Kabelac zkabelac at redhat.com
Fri Jun 20 14:01:39 UTC 2014


Dne 20.6.2014 15:52, Chuck Anderson napsal(a):
> On Fri, Jun 20, 2014 at 02:39:25PM +0200, Dennis Jacobfeuerborn wrote:
>> On 20.06.2014 14:11, Reindl Harald wrote:
>>>
>>> Am 20.06.2014 14:04, schrieb Tim Lauridsen:
>>>> On Thu, Jun 19, 2014 at 8:47 PM, Dennis Gilmore <dennis at ausil.us <mailto:dennis at ausil.us>> wrote:
>>>>
>>>>      In testing dnf on rawhide I nearly always do "dnf clean metadata && dnf update" purely because I found most of
>>>>      the time dnfs metadata was out of date. To me dnf fetching the metadata behind the scenes just doesn't work
>>>>      right. But I'm not sure that me or rawhide fits into the experience dnf is trying to give.
>>>>
>>>>      Dennis
>>>>
>>>>
>>>> Dnf-0.5.2 has a --refresh option, there will a check if the repo metadata is newer than the cached one.
>>>>
>>>> so.
>>>>
>>>> dnf update --refresh will check and update metadata if needed
>>>
>>> *that* would be a useful default instead background-refreshes
>>>
>>
>> I think these are two separate issues. Independent of the background
>> refreshes dnf should always check if its current view of the world is
>> up-to-date (that is the data in its cache is current).
>> This can be fairly important when it comes to security issues. When a
>> fatal exploit is fixed in a package you don't want dnf to say that there
>> are not updates available when this is in fact not true.
>
> Agreed.  In fact, when I'm doing updates (which doesn't happen as
> frequently as it should due to the disruption to work it causes) I
> want to be absolutely sure I'm not working out of a stale cache--I
> often do "yum clean expire-cache; yum update" since I know I can trust
> that to give me the latest updates.  It would be nice if I could just
> trust dnf to do the right thing without resorting to extra command
> line arguments.
>


Well I'm still curious why everyone solves upgrade of metadata, but every 
developer of yum and dnf stays pretty much away of any  'error-case' handling 
situation.

So whenever there is some crash fault during upgrade the installation is left 
broken in the middle - and after decades of rpm/yum development there simply 
doesn't exist tool to fix it.  So yes - skilled user will deal with that, but
I'm pretty sure any unskilled one is directly heading to reinstall...

Also for years Debian supplies short update 'diffs' - so user doesn't have to 
download multiple MB sized files - just couple short small files - again 
something much nicer then running a daemon to download tens of MB on 
background daily...

Zdenek




More information about the devel mailing list