DNF: why does it refresh metadata all the time

[Reindl Harald]

Am 20.06.2014 12:23, schrieb Jan Zelený:
> On 20. 6. 2014 at 11:22:15, Reindl Harald wrote:
>> Am 20.06.2014 09:11, schrieb Jan Zelený:
>>> On 19. 6. 2014 at 14:24:39, Jon wrote:
>>>>> and BTW i am not playing around that much on my Rawhide VM but had
>>>>> *two times* today by type "dnf whatever" the "there is already an
>>>>> instance, wating for PID..." nonsense caused by the background
>>>>> metadata refresh
>>>>>
>>>>> do you *really* think that's a good user-expierience?
>>>>
>>>> No, that is unfortunate, and probably user unfriendly.
>>>
>>> While I agree that the user experience is not pleasant, you are talking
>>> about rawhide. I'd like to ask you not to use rawhide as a reference. We
>>> never intended to optimize dnf for the rawhide use case which is
>>> different in so many ways compared to stable Fedoras
>>
>> that is not matter of rawhide or not and has nohting to do with usecases
> 
> Actually it has everything to do with rawhide. On normal distribution you will 
> not see that lock that often because the metadata doesn't change that often 
> and it doesn't need to be re-downloaded multiple times a day

how does it know that?
because it starts and looks for the metadata!

frankly i have seen so often "checksum does not match try other mirror"
iterating through the whole mirror lists by calling "yum upgrade" which
leads to *a lot* of traffic if you don't stop it

the first time i realized that was PackageKit triggering look for
updates and the reason i got aware about this was my network
widegt and the question "who in the world produces that much
network traffic now and why?"

if you have a small internet package limited to 500 MB per month
which is not that uncommon such default jokes may lead to have
no longer internet for the rest of the month, reduced bandwith
up to unuseable or paying a lot of money



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140620/189c5f1d/attachment.sig>