dnf v.s. yum

[Stephen Morris]

On 06/15/2014 11:23 PM, Ed Greshko wrote:
> On 06/15/14 19:02, Tim wrote:
>> On Sun, 2014-06-15 at 18:27 +0800, Ed Greshko wrote:
>>> OK....  I read FAQ.....
>>>   
>>> http://akozumpl.github.io/dnf/user_faq.html#why-do-i-get-different-results-with-dnf-update-vs-yum-update
>>>   
>>> And the one following it....  "Is it possible to force DNF to get the
>>> latest metadata on dnf upgrade?"
>>>   
>>> Running KDE and the notifications in the systray showed there are 12
>>> updates available.  Figured I give dnf a try, which I've done from
>>> time to time, but it showed no packages to update.  OK....so clean
>>> metadata for both yum and dnf....
>>>   
>>> ran both "yum check-update" and "dnf check-update".
>>>   
>>> yum listed the 12
>> And dnf offered nothing...
>>
>> Is this just a case of whatever generates the metadata that yum uses,
>> and whatever else generates the metadata that dnf uses, do their
>> generation at different times?  Or do they actually have a different set
>> of package files to look through?
>>
>> I can't help but wonder what changing from yum to dnf will do for mirror
>> sites.  Are we going to see a prolonged period where various mirrors
>> stagnate?
>>
> Right....
>
> But, now it does....  I thought "clean metadata" would have done it....  But, clean expire-cache seems to have done the trick.
Can Yum cache updates and DNF cache updates interfere with each other? 
Since installing DNF I randomly get out of space conditions on cache 
updates which I have queried in another thread. I don't understand why 
this occurs when the file I think it is trying to update is 25 GB in 
size and there is 695 GB free space in the partition where the cache is. 
Have you experienced this sort of thing, or should I be raising a bug 
report (the issue with a bug report is at the moment I'm not sure if it 
is DNF or Yum producing the error message, and, if it is Yum, given that 
DNF is replacing Yum in Fedora 22 is anybody going to care anyway?).

regards,
Steve


-------------- next part --------------
A non-text attachment was scrubbed...
Name: samorris.vcf
Type: text/x-vcard
Size: 130 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20140616/ca1b7ae6/attachment.vcf>